Re: [MacPerl-Modules] Re: Need authoritative Apple refs for EOL == CR

[Arved Sandstrom <Arved_37@chebucto.ns.ca>]

On Tue, 2 Mar 1999, Paul J. Schinder wrote:

> On Tue, Mar 02, 1999 at 10:57:49AM -0400, Arved Sandstrom wrote:
> } 
> } Most of the Perl+XML guys aren't this anal. They're actually trying to
> } usefully implement XML. But this discussion went over into the realm of
> } "Is XML flawed?", there's a few straight-XML types involved, and like I
> } say, I have a hunch that *they* will ultimately want paper. That's
> } assuming that they don't just ignore the whole problem.
> 
> OK, now I understand the problem.  (The best thing to do with
> bureaucrats is to ignore them if you can, but you can't.)  It'd help
> if *Apple* would get it right; did you look at the TechNote mentioned
> this morning?  I'm not interested enough to dig into my Java book and
> see if \n is hardwired to \012 in the Java spec (p.s. well, ok.  I
> did.  It is.  That's nuts.  No wonder they need a println.)  . But if
> it isn't, then Apple fouls up again, since the TN assumed it was.
> 
Yeah, I did look at that Technote, then I wished I hadn't. ;-)

For my part, if someone says ASCII newline (NL), then I *always*
understand that to be octal 12, decimal 10, and hex \xA. But I no longer
understand '\n' to be ASCII newline, and it's unfortunate that Java seems
to have made it that way.

> You know the relevant section of the ISO C standard, right?  Matthias
> posted it to the list a long time ago (so long ago that it may be in
> Sandra Silcot's archive).  As I recall, it says that \n is a platform
> dependent symbol for end-of-line straight out, and is not a hard wired
> constant.  I don't know of a reference offhand, but if you can find
> it, that would seem to me to be a show stopper.  (Precedence by
> another official committee and all that.)  Then ask them to consider
> how portable code itself would be if \n were a hardwired constant but
> EOL differed (as they are beginning to realise, it sounds like).

I'm going to be locating it with a quickness. :-) You're quite right - an
official pronouncement pertaining to ISO C would carry some serious
weight.

For what it's worth, let me inject a note of optimism here. As Chris
Nandor already knows, Clark Cooper incorporated changes into the latest
XML::Parser (2.20) that recognize this issue. In point of fact, the new
version builds without porting (although some of the tests still need to
be ported, mostly because of filepath things). Furthermore, as I alluded
to before, the problem really isn't with the XML module authors. A fair
amount of them have weighed in on this, thee seems to be willingness to
work towards a solution, and we'll see what happens.

Unfortunately it looks like the XML spec authors out-clevered themselves.
If, as seems likely, they had the idea that the XML line-break should be
\n, then they were on the right track. But they blew it when they thought
that \n == \xA, and hardwired in the latter (and indeed, the XML spec says
\xA). If they'd just left it at \n, we'd be laughing. But I'm going to hit
them with the ISO C thing, and shake 'em up. :-) [ Mind you, it didn't
hurt that Larry Wall came right out and said maybe there's problems with
the spec, not with the Perl implementation of it. :-) ]

Arved



==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org