Xref: utzoo comp.unix.microport:3580 news.software.b:2565
Path: utzoo!attcan!uunet!mnetor!tmsoft!mason
From: mason@tmsoft.uucp (Dave Mason)
Newsgroups: comp.unix.microport,news.software.b
Subject: another Micorport bug with C news
Message-ID: <1989Jul14.140318.4987@tmsoft.uucp>
Date: 14 Jul 89 14:03:18 GMT
References: <1989Jul13.022941.3573@intacc.uucp>
Reply-To: mason@tmsoft.UUCP (Dave Mason)
Followup-To: news.software.b
Organization: TM Software Associates, Toronto
Lines: 27

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