Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Frank Heckenbach]

David Boyce wrote:

> On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach
> <address@hidden>wrote:
> 
> > FILE is an opaque structure which should never be allocated by user
> > code, so its layout can be implementation specific.
>
> Of course it's an opaque structure. The problem is that the implementation
> can't change its size without breaking binary compatibility with every
> previously-compiled program that uses stdio.

1. It can change its size, precisely because user code does not
   declare variables of type "FILE", just pointers, and does not
   allocate FILE structures itself (but uses fopen() etc.). So as
   long as the size of the pointer remains the same (which is
   trivial), there's no binary compatibility problem. In fact, a
   libc could even use differently sized FILE structures within one
   program (kind of OOP), and user code wouldn't notice.

2. Even if it couldn't change the size, this would only apply within
   one platform. You said: "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". That's not so, as evidenced by my test program. If
   Linux has always had an int there, there's no compatibility
   problem, since programs compiled under original Unix are not
   binary compatible with Linux anyway.

> > In particular, on Linux the field is an int ...
> 
> "Linux" is a pretty elastic term,

Sorry, i686, 32-bit, kernel 3.2.2, Debian squeeze (but I suppose it
applies to all x86 variants, 32-bit, and 64-bit anyway).

> Bottom line, in 32-bit code you have to program for the likelihood that no
> more than 256 streams may be open at once.

This might be right (I was just objecting to your claim that it was
necessarily so on any 32-bit Unix), and I'd prefer to use fd's
anyway.

Indeed, as you suggested earlier, it might be useful to use the main
part of open_tmpfile() (i.e. without the fdopen()), though we'd have
to manually remove the file then. On Unix, we could unlink it right
after opening (since we never need the filename again, unlike the
other users of open_tmpfile()). On Windows, though, this might need
to be delayed, AIUI.