Xref: utzoo news.software.b:2580 comp.unix.microport:3586
Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!ucbvax!agate!apple!sun-barr!newstop!sun!sally!plocher
From: plocher%sally@Sun.COM (John Plocher)
Newsgroups: news.software.b,comp.unix.microport
Subject: Re: another Micorport bug with C news
Message-ID: <116084@sun.Eng.Sun.COM>
Date: 17 Jul 89 20:41:53 GMT
References: <1989Jul13.022941.3573@intacc.uucp> <1989Jul14.140318.4987@tmsoft.uucp>
Sender: news@sun.Eng.Sun.COM
Reply-To: plocher@sun.UUCP (John Plocher)
Followup-To: comp.unix.microport
Organization: Sun Microsystems, Mountain View
Lines: 34

Followups to comp.unix.microport

In article <1989Jul14.140318.4987@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes:
>In article <1989Jul13.022941.3573@intacc.uucp> mann@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