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. This is a well-known problem, easily googled for. Here are a couple of references for Solaris: https://groups.google.com/forum/?fromgroups=#!topic/comp.unix.solaris/yky1fsJ3PMI http://www.oracle.com/technetwork/server-storage/solaris10/stdio-256-136698.html > In particular, on Linux the field is an int ... "Linux" is a pretty elastic term, covering both 32- and 64-bit variants plus many kernels and distros. All 64-bit builds of any system will expand the original unsigned char; the opportunity to break binary compatibility allows for a lot of fixes. For all I know Linux even offers a clever fix in 32-bit versions, but there remain plenty of other 32-bit platforms with the problem. Bottom line, in 32-bit code you have to program for the likelihood that no more than 256 streams may be open at once. -David Boyce
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
