In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Ken Williams) wrote:
> I don't think it's really a good idea to translate newlines in string
> literals (let's lump heretext in with string literals, since that's how
> they function). That stuff is part of the "data" of a program, not part
> of the instruction set.
>
> So by doing one mass CR->LF conversion blindly, you'd get the program to
> run, but it would run differently given the exact same data input. I
> don't think that's desirable.
I disagree. We've been doing this for years on Mac OS without problem.
Whenever I unpack a tarball or fetch a file via FTP or HTTP, my programs are
doing mass/blind newline conversions on text files. It's long been accepted
as the Right Thing, and it only rarely causes problems.
And on the contrary, it would cause major problems to do it the other way,
not only in terms of effort ("Yes, you downloaded the file via FTP as text,
and it converted the newlines from Unix to Mac, but you need to go back and
convert the newlines in string literals back into Unix newlines"), but also
in the simple fact that it would rarely be what we want. When you do a here
doc, 99.99% of the time you want native newlines in there.
The basic tenet is that if you embed an actual newline anywhere at all in
your code, it is a logical newline, no matter where it is or what it is
doing, and it should be converted to the native format of whatever the
target platform is. If you want a literal \012, then you should encode it
as \012 or \0xA or \cJ.
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
