Date: Thu, 2 Nov 1995 22:03:08 +0300 From: "Alexander V. Lukyanov" To: eliz AT is DOT elta DOT co DOT il, kagel AT ts1 DOT bloomberg DOT com Cc: djgpp AT sun DOT soe DOT clarkson DOT edu, jkmarsha AT socs DOT uts DOT edu DOT au Subject: Re: CR/LF pairs... NO NO NO! > From: Eli Zaretskii > Subject: Re: CR/LF pairs... NO NO NO! > > On Thu, 2 Nov 1995 kagel AT quasar DOT bloomberg DOT com wrote: > > > FYI - Both the binary flag ("wb"/"rb") to fopen() and the O_BINARY flag to > > fopen and setmode() are ANSI 'C' compatible so all ANSI compilers, even on > > UNIX, recognize these even when they ignore them. Using these, therefore, will > > not impact code portability. > > I know it for a long time, so this makes two of us. Now if we just could > convince Unix programmers to use it, many porting problems would > magically disappear... > The so called text mode works fine until using fseek/ftell. I saw the bug in Borland C 2,3,4. I didn't test it on gcc, but I'm sure, that it is there in many other compilers. The main source of the bug is in using read/write/char count by stdio. Stdio library use the function read, gets number of bytes read, saves the number in FILE structure. Then, program calls ftell, and stdio returns tell()-count, where tell() returns number of real bytes from the begin of file, and count is the number of logical bytes (ie converted) read from the file and stored in buffer, converted back to number of raw bytes. It is obvious, that the number returned by ftell is wrong. It is logical offset, but there is one small bug, the 'count' was conwerted to and back supposing that every '\n' is followed by '\r'. So all works until the file conteins plain text in MS-DOS format. But when it is in UNIX format, the bug can appear. Well, at last, the program may expect, that the number of bytes read from file match to offset in file, but in text mode it is not so. --- Alexander Lukyanov lav AT video DOT yars DOT free DOT net