> 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 meant Windows specific
> > HANDLE objects (which underly every open file).
>
> I'm not very familiar with Windows terminology. Is a HANDLE equivalent
> to a UNIX file descriptor? Or is it a third thing, different from UNIX
> fd's or C standard FILE*'s?
It is a third thing. It is a pointer to an opaque object, returned by
the OS primitives that open a file. The C runtime layer then
maintains an array of structs where it keeps information about each
open file, and an index into that array is the file descriptor.
> > Anyway, I'm not sure why the current code calls tmpfile, which
> > produces a FILE object, but then only uses its file descriptor and
> > read/write functions. Why not keep the FILE object in the child
> > struct, and use fread/fwrite instead?
>
> 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.
> Also, a stream is much more resource-heavy than a file descriptor, as it
> implies buffering etc. in addition to the open file. We wouldn't use
> the buffering, but it's still there.
What's wrong with using the buffering?
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
