Bug in Microport stdio
Jonathan Corbet
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
Daniel M. Frank
>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%cas...@spool.wisc.edu
Daniel M. Frank
That should be
fp->_flag |= _IOWRT ;
Daniel R. Levy
>In article <1...@gaia.UUCP> j...@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
Daniel M. Frank
>> 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).
Larry V. Streepy
>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.
>
>
>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!l...@seismo.css.gov CSNET: ndmce!gcg!lvs@smu