Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!usc!snorkelwacker!mit-eddie!bbn!bbn.com!rsalz
From: rsalz@bbn.com (Rich Salz)
Newsgroups: comp.os.minix
Subject: Re: POSIX
Message-ID: <2089@prune.bbn.com>
Date: 26 Oct 89 18:47:05 GMT
References: <3819@ast.cs.vu.nl>
Organization: BBN Systems and Technologies Corporation
Lines: 24

In <3819@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) says he found a
"gross bug" ross bug in Doug Gwyn's directory: "if you call closedir()
with a dirp that has already been closed" the free inside closedir()
will bomb.  He then says he "fixed" it by putting a magic number which
is checked, then cleared, by closedir(). 

Well gee, strcpy() can blow up if either parameter is a null pointer.
Gonna fix that?  fprintf("%d", 5) can blow up.  Gonna fix that?
The point is that you're if you call closedir() twice you've broken the
rules.  Don't do that, and don't slow down standard library routines by
bullet-proofing that way.  You just do a half-way, inconsistent job, that
helps hide bugs when code is ported.  BSD did NOT do the world a favor
by making it legal to deference location zero -- ask anyone who's ported
poor code from BSD to Sun, for example.

As a minor point, the "fix" mentioned above isn't bulletproof, either.
It is not impossible that I pass a garbage pointer into closedir() that
just happens to point to some place with the same magic number.

Please don't distribute these changes.
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.