On Wed, Apr 17, 2013 at 1:00 PM, Eli Zaretskii <e...@gnu.org> wrote:
> > I believe the thinking is that some implementations may have a much
> > smaller number of open streams (FILE*) allowed, than open file
> > descriptors. The POSIX standard, for example, allows this:
> >
> > > Some implementations may limit {STREAM_MAX} to 20 but allow {OPEN_MAX}
> > > to be considerably larger.
>
> I'd be surprised if this were a real problem nowadays. E.g., the
> Windows C runtime is documented to allow up to 512 FILE streams, which
> can be enlarged to 2048 by calling a function. The max number of file
> descriptors is also 2048.
>
That's not the way it is on Unix. My understanding, and I believe this
applies to all Unix variants, is that because the original stdio FILE
structure used an 8-bit int to hold the file descriptor, the number of
available streams is <256 always and forever (in 32-bit variants - 64-bit
builds fix lots of limits). I don't know of any Unix variants which don't
allow at least 1024 descriptors, and some allow the limit to be raised
dynamically without bound, but the limit on descriptors *associated with
streams* is fixed at 256.
I believe this was all documented in comments in the original patch I sent
in.
-David Boyce
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
