jon@gaia.UUCP (Jonathan Corbet) (10/30/86)
I have found what appears to be an obnoxious bug in the standard I/O library for Microport unix. Rather than let other folks out there track it down themselves, I thought I would pass it on: Essentially, the problem is this: when you fopen() a file for "r+" access, read from the file, then attempt to write, the data written gets lost. This happens even if you are careful to do a fseek() like the manual says. This breaks certain software, such as netnews. The solution I have found is to get the current position with ftell(), close and reopen the file, fseek() to the position of interest, then do the write. This little program demonstrates the bug. Simply compile (large OR small model), create a file "bug.test", and run it. You can then see that bug.test is not changed. # include <stdio.h> main () /* * Demonstrate uPort stdio bug. */ { FILE *fp; int i; /* * Open up the file. */ if ((fp = fopen ("bug.test", "r+")) == NULL) { perror ("Can't open bug.test"); exit (1); } /* * Now we read a little ways into it, then write. Do the fseek, as required * by the manual entry. */ for (i = 0; i < 100; i++) fgetc (fp); if (fseek (fp, ftell (fp), 0)) { perror ("Fseek error"); exit (1); } fprintf (fp, "YOU SHOULD SEE THIS!"); fflush (fp); fclose (fp); } -- Jonathan Corbet {hao | nbires}!gaia!jon
dan@prairie.UUCP (Daniel M. Frank) (11/01/86)
In article <123@gaia.UUCP> jon@gaia.UUCP (Jonathan Corbet) writes: >I have found what appears to be an obnoxious bug in the standard I/O >library for Microport unix. Rather than let other folks out there track >it down themselves, I thought I would pass it on: A couple clarifications: this bug appears in most SVR2 releases. This should be no suprise, since Microport is an AT&T licensee. It appears in printf, fprintf, vprintf, and vfprintf. Microport is aware of the problem, and it is being repaired. The best, and least cost workaround, is to do the following after any call to these routines (assume your file pointer is called fp): fp->flag |= _IOWRT ; You don't have to close the file, or anything. Do this only if the file is opened for "r+" mode. -- Dan Frank uucp: ... uwvax!prairie!dan arpa: dan%caseus@spool.wisc.edu
dan@prairie.UUCP (Daniel M. Frank) (11/01/86)
That should be fp->_flag |= _IOWRT ; -- Dan Frank uucp: ... uwvax!prairie!dan arpa: dan%caseus@spool.wisc.edu
levy@ttrdc.UUCP (Daniel R. Levy) (11/02/86)
In article <272@prairie.UUCP>, dan@prairie.UUCP (Daniel M. Frank) writes: >In article <123@gaia.UUCP> jon@gaia.UUCP (Jonathan Corbet) writes: >>I have found what appears to be an obnoxious bug in the standard I/O >>library for Microport unix. Rather than let other folks out there track >>it down themselves, I thought I would pass it on: > A couple clarifications: this bug appears in most SVR2 releases. (Not on the 3B20.) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
dan@prairie.UUCP (Daniel M. Frank) (11/04/86)
In article <1290@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >> A couple clarifications: this bug appears in most SVR2 releases. >(Not on the 3B20.) Note I said, "most". All of AT&T's Unix software for its own machines seems more up-to-date and better maintained than its software for such things as Vaxen (which, I am told, DO have the bug). -- Dan Frank uucp: ... uwvax!prairie!dan arpa: dan%caseus@spool.wisc.edu
lvs@gcg.uucp (Larry V. Streepy) (11/05/86)
In article <123@gaia.UUCP> jon@gaia.UUCP (Jonathan Corbet) writes: >I have found what appears to be an obnoxious bug in the standard I/O >library for Microport unix. Rather than let other folks out there track >it down themselves, I thought I would pass it on: > >Essentially, the problem is this: when you fopen() a file for "r+" access, >read from the file, then attempt to write, the data written gets lost. This >happens even if you are careful to do a fseek() like the manual says. >This breaks certain software, such as netnews. The solution I have found >is to get the current position with ftell(), close and reopen the file, >fseek() to the position of interest, then do the write. > > [text of test program removed] > >Jonathan Corbet >{hao | nbires}!gaia!jon This problem also manifests itself on the AT&T PC6300+. I had the same problem bringing up netnews (i.e. the ACTIVE file wasn't being updated). The problem can be worked around in a slightly more efficient manner. After opening the file set the stream to unbuffered via setbuf(3S). as an example: if( (fp = fopen( "file_to_open", "r+" )) == NULL ) { /* handle error */ } else setbuf( fp, (char *)NULL ); /* rest of code */ When I applied this to the test program Jonathan supplied it worked fine. Larry V. Streepy, Jr. "Waiting is" The Genesis Group of Consultants, (214)530-6884 2905 Green Oaks Dr., Garland Tx, 75040 USA UUCP: {seismo!c1east | cbosgd!sun | allegra}!convex!ndmce!gcg!lvs INTERNET: ndmce!gcg!lvs@seismo.css.gov CSNET: ndmce!gcg!lvs@smu