Mail Archives: cygwin/1997/01/27/22:59:43
Paul Shirley wrote:
>
> In message <c=US%a=_%p=msft%l=RED-67-MSG-970127183114Z-12470 AT INET-
> 04-IMC.microsoft.com>, Stephan Mueller <smueller AT MICROSOFT DOT com> writes
> >I agree that the 't' flag is really handy to have around.
> >
> >IMO, the only way to truly solve this problem once and for all is to
> >gradually incorporate text/binary mode awareness into the official GNU
> >sources. That means that all fopens that really mean to open in binary
> >should have the 'b' added, and all code that follows fopens that really
> >mean text mode should be examined and changed if they assume things like
> >'the size of the file equals the number of charcters in a read of the
> >whole file'. The code isn't 'bad' the way it is, it's just
> >Unix-centric, and not entirely ANSI conformant.
Of course it's Unix-centric; it's GNU code, and GNU project is a Unix
emulation. Of course it isn't entirely ANSI conformant; *no* complex or
professional-quality code is entirely ANSI conformant (and I say this as a
former member of X3J11, the ANSI C standards committee). GNU code isn't even
entirely POSIX compliant, and POSIX is what's relevant here.
> >It will be more useful
> >and more portable if these things are fixed, and I'm sure in time they
> >will be.
Why be sure of something that's probably false? The GNU project has limited
goals, and they explicitly do not include 16-bit systems, systems that don't
use / in filenames, systems that have separate text and binary modes, etc.
Notably, in POSIX systems, reading as many bytes from a file as stat says it
contains is perfectly appropriate behavior, and GNU code won't be "dumbed"
down for the sake of non-POSIX systems.
> AFAIK the djgpp port already handles 't' and O_TEXT modes. I had assumed
> that this came from the gnu sources ( I assumed that because who else
> would add an O_BIN flag when native DOS compilers all use O_BINARY ;)
Well, if djgpp defined O_BIN, then obviously djgpp would. There is no
't' or O_TEXT or O_BIN or O_BINARY mode in GNU. And there is no 't'
mode defined in ANSI, nor is there any open() call in ANSI to even take
an O_BINARY or O_TEXT flag.
> If not, borrowing from the djgpp source should be fairly
> straightforward.
ANSI does not provide for defaulting to binary when there are both text and
binary file modes, so borrowing this would not make cygwin consistent with
ANSI or POSIX.
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -