eli@spdcc.COM (Steve Elias) (06/17/88)
From: Gary Ross <sun!valid!gdr> I am running version 4.0 of the c compiler and the specific problem is that the file read operation does not appear to work correctly. More specifically I have a file of a given size (according to several different utilities that I have used) and when I try to read it with my c program it craps out half way through the file and is unable to find the rest of the data.
lotto@wjh12.harvard.edu (Jerry Lotto) (06/17/88)
In article <1327@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: >From: Gary Ross <sun!valid!gdr> >the file read operation does not appear to work correctly. More specifically >I have a file of a given size (according to several different utilities that >I have used) and when I try to read it with my c program it craps out half >way through the file and is unable to find the rest of the data. How was this file opened? uSoft C treats files opened as ASCII in cruel and unusual ways. Expanding CR-LF and Treating character data ^Z as EOF are features of 'read'ing a file opened as ASCII. Actually MS-DOS programs in general are often guilty of ignoring directory size entries completely. Dump the file and look for a ^Z or open it as binary data, and your problem has a reasonable chance of disappearing. -- Gerald Lotto - Harvard Chemistry Dept. UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto ARPA: lotto@harvard.harvard.edu
tat00@amdahl.uts.amdahl.com (Tom Thackrey) (06/18/88)
In article <1327@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: >From: Gary Ross <sun!valid!gdr> > >I am running version 4.0 of the c compiler and the specific problem is that >the file read operation does not appear to work correctly. More specifically >I have a file of a given size (according to several different utilities that >I have used) and when I try to read it with my c program it craps out half >way through the file and is unable to find the rest of the data. This sounds like the problem of reading a binary file in character mode and encountering an 'end-of-file' character half way through. I've been doing a lot of data prep using MSC 4.0, 5.0 and 5.1 and haven't encountered any file i/o bugs (I use the small and compact models mostly.) -- Tom Thackrey tat00@amdahl.uts.amdahl.com <=> amdahl!tat00 [ My opinions are only my own. ]
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/20/88)
This one is not a bug, it's a feature (really). The reason the b for
binary qualifier was added to fopen by X3J11 is that a number of
operating systems write a file format for text which contains something
other than the data passed to fwrite. Microsoft could have read the
files litterally, leveing the user to filter out the CR's and know that
^Z meant EOF, but they did it for you, and gave you the binary option so
you could read raw data as written.
It soulds to me as if the wrong method of reading the data was chosen,
followed by a bug report because it didn't do what was expected. I've
done that myself, although it's less embarassing when I do it directly
to the vendor rather than worldwide.
The largest need for this is in the VAX/VMS area, where there are (I
believe) 11 file formats, only one of which contains the data written by
the user, all the data, and nothing else. You can easily identify it
because it's called something like "LF delimited binary stream" format.
Should you use any other, you hope your C runtime does the translation
into text for you, so you don't have to do it yourself.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me