Re: More patch 2.5.9 hacking

[Benjamin Riefenstahl]

Hi Eli,


>> From: Benjamin Riefenstahl <address@hidden>
>> You are either on Unix or on DOS/Windows, and the runtime only
>> needs to handle the native convention.

"Eli Zaretskii" <address@hidden> writes:
> I don't think I understand this.  ``Normal'' C code is written with
> the Unix EOL format in mind, so it assumes a single \n at the end of
> each line.  Text-mode I/O was invented to make this happen
> automagically on DOS/Windows platforms.

I agree, but I'd phrase it slighly different.  The definition is made
in the C specs without reference to specific platforms.

C code sees line ends as \n, where \n is a single character whose
actual value is defined by the compiler vendor.  The C runtime
translates that to and from an external format as required on the
platform.

In practice on Unix the translation is trivial, \n == LF, \r == CR and
this is also the platform convention.  On Mac OS Classic CR was the
external convention, and there are two types of implmentations, either
\r and \n are switched during I/O or they are just re-defined as \n ==
CR and \r == LF (nasty but legal).  On Windows the external
representation is CRLF, so this is translated to and from \n on I/O.
There are even other conventions, or so I have heard.

Each platform only cares for it's particular native format and Unix
format is not special on the other platforms.  In the age of Internet
and cross-platform exchange of files of all kinds, we may not like
those limited definitions, but that is how the C language is defined
(modulo my own misunderstandings, of course).  The fact that reading
Unix text files on Windows usually works with C programs is pure
coincidence, it is not intentional in the sanse that it is fully
supported by VC++ or Borland.  If it doesn't work for some operation,
you're on your own.

> The solution is to fix the library function

You usually don't do that with commercial compilers because of
licenses and/or practical problems such as hassles with upgrading and
the need to re-patch.  You could try to persuade the vendor to change
it's implementation, but that would go into the category "new
feature", not into "bugs."  So in the end this is not really an option
for portable C code.

> or to use binary I/O (and remove the \r characters manually) or to
> replace fseek/ftell with equivalent code.

As I said.


benny