Path: utzoo!utgpu!attcan!uunet!husc6!purdue!decwrl!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.bugs.sys5
Subject: Re: Serious bug in stdio on some ``System V'' derivatives
Message-ID: <23127@amdcad.AMD.COM>
Date: 5 Oct 88 03:46:19 GMT
References: <591535074.12423@minster.york.ac.uk>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 32

In article <591535074.12423@minster.york.ac.uk> bin@minster.york.ac.uk writes:
+---------------
| Berkeley networking has nothing to do with this, of course, except
| that ``System V'' systems that have sockets (and perhaps NFS) seem
| to be more likely to increase NOFILE...
| Berkeley systems, including Suns, are unaffected, since they sensibly
| put the extra value in the FILE structure.
+---------------

Well, having just done a port of the Berkeley networking code into a System-V,
let me point out that whoever ported your stuff had to fix a related problem
I ran into over and over, a problem due to the *#&^$*#& "_bufendtab[]" which
(as you say) does not exist in Berkeley systems:

If you do an "freopen" of a file descriptor which is already open in
an stdio stream, since the "_bufendtab[]" is indexed by *file descriptor*
your new FILE will stuff *its* bufend over the *old* FILE's. This will
cause illegal memory references and other assorted mayhem if you ever
use the old FILE for anything!  (*Hack* solution: change all cases of such
"freopen(s,...) to "freopen(dup(s),...)", so as to get a new bufend entry.)

Having _bufend be in a table indexed by f.d. instead of FILE* was  a ghastly
mistake. I certainly hope more recent versions of System-V have fixed it.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403