Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!gatech!hubcap!ncrcae!ncrlnk!uunet!mcvax!hp4nl!mhres!jv
From: jv@mhres.mh.nl (Johan Vromans)
Newsgroups: comp.sources.d
Subject: Re: PAX : Too many open files
Message-ID: <2895@mhres.mh.nl>
Date: 18 Feb 89 22:42:22 GMT
Organization: Multihouse NV, the Netherlands
Lines: 36

In article <6510@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) wrote:
> wietse@wzv.UUCP (Wietse Z. Venema) wrote:
> > Just found a mistake in the code; where closedir() should be called, the
> > program invokes the close() function...
> > 
> > < 		close(dirp);
> > ---
> > > 		closedir(dirp);
> 
> Note that the problem would've been found a long time ago had this program
> been checking the results of its system calls...  (Yes, Virginia, a "close()"
> CAN fail!)

This remembers me to one of the nice features of Burroughs
Extended Algol, running on B6700/B7700 mainframes.
In this language, you could check for the result of an IO
operation, and handle accordingly. If you did not check the
result, code to call a system-supplied exception handler was
inserted by the compiler. In all situations, exceptions were
trapped unless you explicitly ignored the result of the call,
e.g.: 
	result := read (......);
	% do nothing with 'result'

If you just called 'read(...)' the compiler generated code as if
you wrote:
	if read(...) then handleIOerror(...);

Of course, this is only possible because the IO operations were part
of the language, like in Pascal, and not a separate package, like
in C. 
But things like "unchecked system calls" did not exist .....
-- 
Johan Vromans			 jv@mh.nl via european backbone (mcvax)
Multihouse [A-Za-z ]* [NB]V			uucp: ..!mcvax!mh.nl!jv
Gouda - The Netherlands				  phone: +31 1820 62944