Xref: utzoo news.software.b:2572 comp.unix.microport:3581
Path: utzoo!utgpu!watmath!att!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: news.software.b,comp.unix.microport
Subject: Re: another Micorport bug with C news
Summary: Add one line, fix the bug in AT&T's stdio
Message-ID: <1989Jul16.203553.11304@ddsw1.MCS.COM>
Date: 16 Jul 89 20:35:53 GMT
References: <1989Jul13.022941.3573@intacc.uucp> <1989Jul14.140318.4987@tmsoft.uucp>
Reply-To: karl@ddsw1.MCS.COM (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 27

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.

Try adding this after EACH write (fprintf, fputs, etc) call:

fp->_flag |= _IOWRT;

("fp" is your file pointer)

This bug is in most System V STDIO's before SVR3, and may even be in there
as well.  It is NOT present in Xenix or BSD stdio's.  The symptom is that a
write made to a file open for update will not show up in the file, even if
you follow the rules and "seek" before a write is done after a read.

This one was VERY frustrating to us, but we finally found and squashed the
problem (I was about to toss stdio entirely from one of our packages at one
point due to this one).

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"