Path: utzoo!mnetor!uunet!mcvax!cernvax!ethz!zu
From: zu@ethz.UUCP (Urs Zurbuchen)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C bug (?)
Message-ID: <308@bernina.UUCP>
Date: 23 Feb 88 08:19:35 GMT
References: <734@agora.UUCP>
Reply-To: zu@bernina.UUCP (Urs Zurbuchen)
Organization: ETH Zuerich, CS Department, Switzerland
Lines: 33

In article <734@agora.UUCP> qintar@agora.UUCP (Jim Seymour) writes:
>In version 1.0 I noticed what seemed to be a bug in the read() function.
>The docs claim (and the standard dictates) that this function returns the
>actual byte count read in from the file.  I had a program written originally
>for the Manx Aztec C compiler which read data from a file in 16 byte chunks
>and checked the return code to verify how many bytes were read.

I stumbled on that problem this weekend, too, when porting some Unix software
to the MS-DOS environement.
The problem lies with brain-damaged MS-DOS. All C compilers which handle
text files as collection of lines ending in CR-LF will show that behaviour.
It is, for example, true for MS-C (4.0), too.
Internally, lines of a text file are ended by a LF only. On read time every
CR-LF pair is translated into a single LF. When writing to a text file, all
LF's are expanded to CR-LF. The number returned by read is the actual number
of bytes in the buffer which it read to. Write might return a similar value.

Now, you might wonder how the program knows which files to handle as text
files and which as binaries. The solution is simple. It doesn't. The
programmer has to know itself. You can add a parameter 'b' to the file open
mode string in fopen() or set the translation mode with setmode() or include
the constant O_BINARY in an open() call. This will prevent translation of
CR-LF to LF and vice versa. It also allows to write ^Z which doesn't work
on text files.
By the way, all files are text files by default.
As a solution you could treat all your files as binary files. But be sure then
to replace eoln() with your own function. It doesn't recognize CR as end of
line. Perhaps you would have to replace other functions as well.

		Hope this helps,
		     ...urs

UUCP: ...seismo!mcvax!cernvax!ethz!zu