[comp.std.unix] Killing programs that close

andrew@lemming.gwd.tek.com (Andrew Klossner) (06/30/87)

From: andrew@lemming.gwd.tek.com (Andrew Klossner)

[With regard to programs that inadvertantly do close(-1):]

	"Programs that are not that pessimistic are broken.  I see no
	reason to reject this proposal out of hand merely because it
	would expose bugs in programs such as these ..."

One of the major goals of a standardization effort is to "do no harm":
not to invalidate facilities which are commonly available and upon
which many programs may depend (even if such dependence is
inadvertant).  The requested facility, to close all open files, could
just as easily be implemented with a new function, e.g., "closeall()".
There is no reason to go out of our way to overload an existing
function, one whose semantics have been fixed for over a decade.

A much more extreme example of this philosophy appears when Unix
vendors go out of their way to place zeros at location 0, so that
programs developed on VAXes which "expect" to find 0 when dereferencing
a 0 pointer will work.  No, I'm not suggesting that POSIX or X3J11
mandate this, but vendors such as my employer do this for marketability
reasons.  Imagine that a potential customer has one of my workstations
and one of yours; on yours their VAX application compiles and runs just
fine, while on mine it crashes with "bus error".  No amount of my
explaining that their program shouldn't dereference a null pointer is
going to get me the sale unless my machine stands out in other ways.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]

Volume-Number: Volume 11, Number 83