Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!ut-sally!std-unix
From: std-unix@ut-sally.UUCP
Newsgroups: comp.std.unix
Subject: open file range
Message-ID: <8271@ut-sally.UUCP>
Date: Mon, 15-Jun-87 04:50:23 EDT
Article-I.D.: ut-sally.8271
Posted: Mon Jun 15 04:50:23 1987
Date-Received: Thu, 18-Jun-87 00:45:54 EDT
Sender: std-unix@ut-sally.UUCP
Reply-To: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
Lines: 15
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

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