Date: Fri, 28 Sep 2012 18:47:39 -0400 From: John Baldwin <jhb@freebsd.org> To: arch@freebsd.org Subject: stdio and short file descriptors revisited Message-ID: <201209281847.39663.jhb@freebsd.org>
next in thread | raw e-mail | index | archive | help
Four years or so ago I cleaned up some of the stdio internals as fallout from running into problems with stdio using a short instead of an int to hold file descriptors. Back then I got sidetracked with attempting to make FILE opaque and ended up never getting around to bumping _file from a short to an int. I recently ran back into the SHRT_MAX limit at work again and came up with a patch to fix this. To preserve the ABI, it is necessary to leave the existing short _file in place and add a new int _file to the end of the FILE structure. Also, for old applications, the old _file (_ofile in the patch) must still be valid. The approach I have taken is to bump the symbol version for routines that create FILE objects with a non-fake _file (fopen, fdopen, and freopen). The old FBSD_1.0 variants still fail if an fd is greater than SHRT_MAX (and thus cannot be safely stored in _ofile). The new FBSD_1.3 variants assign to both _file and _ofile if the fd is less than SHRT_MAX. I also changed fileno() to no longer be an inline macro in <stdio.h> but to always be a function call going forward. If folks think this is ok, I'll hack up a modified version that hides _file from outside consumers (rename it to _nfile or some such) and send it for a ports-exp run before committing to make sure there aren't any 3rd party apps accessing _file directly. http://www.FreeBSD.org/~jhb/patches/stdio_file.patch -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209281847.39663.jhb>