Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: bug in pclose(3)
Message-ID: <9441@smoke.BRL.MIL>
Date: 19 Jan 89 14:51:51 GMT
References: <261@ecijmm.UUCP> <14020053@hpisod2.HP.COM> <803@auspex.UUCP> <9410@smoke.BRL.MIL> <9003@elsie.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <9003@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>> > >Don't people EVER learn from experience?
>> >No they don't, as a look at the changes made to function library interfaces
>> >by the dpANS shows.
>> What changes?  Having just checked over my System V "lint" library for
>> pANS conformance, I didn't notice any actual changes.
>Check out the memory allocation functions (with their changed treatment of
>NULL arguments) and fopen (where "rb+" is given new meaning) for starters

The only changes regarding memory allocation and NULL arguments are that
in an ANSI C Standard conforming hosted implementation, realloc() acts
like malloc() when fed a null pointer, and free() of a null pointer is
benign.  Both those are upward compatible with previously existing
practice; correct code using these functions will not be broken by the
extensions.  Similarly for the fopen() example.  "rb+" simply HAD no
correct meaning in old UNIX implementations; using it there would have
been a (possibly undetected) bug.  Again this is an extension.  UNIX
(or POSIX) implementations need not use "rb+" at all; "r+" is equivalent
in those environments; thus no existing correct code has been invalidated
by this (necessary!) extension.

The suggestion that prompted this discussion was INCOMPATIBLE with the
already-established standard usage for the function.  Therefore a new
name should have been used, not the standardized name.