From: Paul Smith psm...@gnu.org
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 psm...@gnu.org
Cc: bo...@kolpackov.net, bug-make@gnu.org,
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. Is
From: Paul Smith psm...@gnu.org
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
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.
GNU
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
