[news.software.b] another Micorport bug with C news

mann@intacc.uucp (Jeff Mann) (07/13/89)

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.
I believe that this is a bug in the Microport software, but  whether  it
is in fseek, or somewhere else, I don't know.

In  relay/history.c,  in  the history() function, the fseek() causes the
subsequent fprintf of the history line to fail if the history  file  had
already  been  opened  and  written  to.   This  means you will get many
articles installed (relaynews doesn't complain when it happens)  without
history entries, and they can't be expired (use mkhist to find them).

My  workaround is to move this fseek from where it is to right after the
fopenwclex in openhist(), and to rely on the fact that the file  pointer
will  be left at EOF after any writes.  However, gethistory() also calls
fseek() when it needs to get  a  history  line.   The  only  place  that
gethistory()  is called is from control.c when cancelling an article.  I
changed gethistory() to close the history  file  after  doing  so.   (Oh
yeah,  gethistory  is also used in the ihave/sendme stuff, but I haven't
looked at how this would affect it.)

I think this  will work, but I haven't really tested it.  I'd appreciate
any better ideas...


-- 
| Jeff Mann - Inter/Access, Toronto           ...uunet!mnetor!intacc!mann  |
| "A picture is worth 256 thousand words"  {utzoo, utgpu}!chp!intacc!mann  |

mason@tmsoft.uucp (Dave Mason) (07/14/89)

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.

>I believe that this is a bug in the Microport software, but  whether  it
>is in fseek, or somewhere else, I don't know.

I have been running an earlier version of Cnews for just under a year.
I had the same problem on a System Vr2 NS32000 box.  I didn't figure
out the exact source of the bug (it is some interaction between fseek
and fprintf), but I changed that code to do an sprintf followed by a
fwrite, and the problem was solved (only took 10 frustrating hours to
figure out what was going wrong & fix it!) I mentioned this to Geoff
in January, but he was reluctant to work around buggy stdio
implementations, and didn't want to have a limited string size that
the sprint solution implies (though that too could be worked around).

I had hoped that the partial stdio package that comes with the current
release would solve this problem, but I haven't had the time to start
installing the new release yet.  Did you try using the supplied stdio
package rather than the one from your supplier?
	../Dave

karl@ddsw1.MCS.COM (Karl Denninger) (07/17/89)

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"

plocher%sally@Sun.COM (John Plocher) (07/18/89)

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