> From: Paul Smith
> Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de
> Date: Tue, 16 Apr 2013 12:56:21 -0400
>
> On Tue, 2013-04-16 at 19:20 +0300, Eli Zaretskii wrote:
> > > From: Paul Smith
> > > Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de
> > > Date:
On Wed, 2013-04-17 at 19:10 +0300, Eli Zaretskii wrote:
> That could be a misunderstanding on my part: I didn't realize that by
> "handle" you mean a FILE object. I thought you meant Windows specific
> HANDLE objects (which underly every open file).
I'm not very familiar with Windows terminology.
> From: Paul Smith
> Cc: bug-make@gnu.org, f.heckenb...@fh-soft.de
> Date: Wed, 17 Apr 2013 13:11:29 -0400
>
> On Wed, 2013-04-17 at 19:10 +0300, Eli Zaretskii wrote:
> > That could be a misunderstanding on my part: I didn't realize that by
> > "handle" you mean a FILE object. I thought you mean
On Wed, 2013-04-17 at 23:00 +0300, Eli Zaretskii wrote:
> 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.
On Wed, Apr 17, 2013 at 1:00 PM, Eli Zaretskii 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
