[comp.std.unix] open file range

std-unix@ut-sally.UUCP (06/15/87)

From: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>

Some implementations may not have any definite upper limit
(at least, nothing less than several thousand) for the number
of open files supported per process.  The minimum guaranteed
number of open files available is useful (for example for
merge sorting), but the maximum number may not be meaningful.

I submitted a proposal to X3J11 that fflush((FILE*)NULL) would
flush ALL output buffers, since there is no other good way to
accomplish that.  It seems that close(-1) might be a similar
solution for POSIX.  (Since nobody is supposed to be doing this
currently, it is available for assigning new semantics to.)

Volume-Number: Volume 11, Number 64

simon@its63b.ed.ac.uk (Simon Brown) (06/18/87)

From: simon@its63b.ed.ac.uk (Simon Brown)

In article <8271@ut-sally.UUCP> Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA> writes:
>From: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
>
>I submitted a proposal to X3J11 that fflush((FILE*)NULL) would
>flush ALL output buffers, since there is no other good way to
>accomplish that.  It seems that close(-1) might be a similar
>solution for POSIX.  (Since nobody is supposed to be doing this
>currently, it is available for assigning new semantics to.)
>

Arghhh, no! Don't do that! Ok, it might seem a truly wonderful idea, but
it would mean that things like
	fd = open(some-random-filename,something);
	do-something-bizarre-with-fd;
	close(fd);
will do a "close(-1)" if the open happened to fail for some reason or other,
which is harmless at the moment (just returns -1, errno=EBADF), but would be
a bit tragic with this new semantics!
Yes, I know this isn't a problem if everyone always checks the return-value
from open(), creat(), etc..., but lots of programs aren't that pessimistic!

-- 
----------------------------------
| Simon Brown 		         | UUCP:  seismo!mcvax!ukc!{its63b,cstvax}!simon
| Department of Computer Science | JANET: simon@uk.ac.ed.{its63b,cstvax}
| University of Edinburgh,       | ARPA:  simon%{its63b,cstvax}.ed.ac.uk ...
| Scotland, UK.			 |				@cs.ucl.ac.uk
----------------------------------	 "Life's like that, you know"

Volume-Number: Volume 11, Number 74

guy@Sun.COM (Guy Harris) (06/20/87)

From: guy@Sun.COM (Guy Harris)

> ...it would mean that things like
> 	fd = open(some-random-filename,something);
> 	do-something-bizarre-with-fd;
> 	close(fd);
> will do a "close(-1)" if the open happened to fail for some reason or other,
> which is harmless at the moment (just returns -1, errno=EBADF), but would be
> a bit tragic with this new semantics!
> Yes, I know this isn't a problem if everyone always checks the return-value
> from open(), creat(), etc..., but lots of programs aren't that pessimistic!

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; indeed, the fact that it exposes
these bugs might be an excellent reason to do it - it is very
aggravating to deal with programs that exhibit this sort of unwarranted
optimism, as they do not give very good error indications when this
optimism is unwarranted (if they bother giving one at all!).


Volume-Number: Volume 11, Number 75