🚀 go-pugleaf

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

   That should be

	  fp->_flag |= _IOWRT ;


-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus@spool.wisc.edu

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

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

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