David Boyce wrote: > On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach > <f.heckenb...@fh-soft.de>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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
