another Micorport bug with C news

[John Plocher]

Followups to comp.unix.microport

In article <1989Jul14.140318.4987 at tmsoft.uucp> mason at tmsoft.UUCP (Dave Mason) writes:
>In article <1989Jul13.022941.3573 at intacc.uucp> mann at intacc.UUCP (Jeff Mann) writes:
>>I'm not sure how far this problem goes, but on this System V/AT rel 2.3,
>>fseek(3)  causes  some  weird action from relaynews.  It seems that when
>>working with a file which  has  been  opened  for  update  (read/write),
>>performing  an  fseek after any writes causes subsequent writes to fail.
>
>Actually they don't fail, they just all start at the same place in the
>file, as I remember the problem, so only the last remains in the file.

The problem is a generic System Vr2 bug in many/most Vr2 systems.  I extracted
the following from Microport's bug database:

Bug 404 Rel 1.36 priority 3:
Using fprintf to write to a file opened in "r+" mode will cause data written
with fprintf() to be lost if fseek()s are done also.

Reason:
The code in the stdio library provided with Systen Vr2 incorrectly modifies
the _flag member of the FILE * structure when writing to a "r+" stream.

Work Around:
Set the _IOWRT flag by hand after each fprintf():
	{
		FILE *fp;
		...
		fprintf(fp, "format", args);
		fp->_flag|=_IOWRT
		...
	}

    -John Plocher