bug in pclose(3)

[Doug Gwyn]

In article <9003 at elsie.UUCP> ado at 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.