Date: Wed, 27 Feb 2008 17:59:25 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, Garrett Wollman <wollman@hergotha.csail.mit.edu> Subject: Re: Cleaning up FILE in stdio.. Message-ID: <20080227065925.GK83599@server.vk2pj.dyndns.org> In-Reply-To: <200802262355.16519.jhb@freebsd.org> References: <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> <200802262355.16519.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--dgjlcl3Tl+kb3YDk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2008 at 11:55:16PM -0500, John Baldwin wrote: >Yes, I discovered the macros today while working on my fd as short problem= =2E =20 Macros and __inline functions mean that a significant proportion of software compiled on FreeBSD has the existing definition of FILE compiled into it. >However, I can't fix the fact that our stdio can't handle fd's > SHRT_MAX= =20 >(again, glibc handles this just fine) w/o making a royal mess. I don't think a versioned FILE is practical so we are stuck with a 16-bit _file for the immediate future. >What I've gone with instead to fix the SHRT_MAX problem is to change=20 >fopen/fdopen/freopen to fail to use fd's > SHRT_MAX with an error. You could change _file from 'short' to 'unsigned short' without breaking the ABI - this would allow either 65535 or 65536 file descriptors (I'm not sure whether _file =3D=3D -1 is special or not). This would postpone the problem for some time. My suggestion would be: Now: a) change _file to 'unsigned short' and add checks as proposed b) merge __sFILEX into FILE c) Remove the macros and inlines that poke around inside FILE d) Note that directly accessing FILE innards is deprecated and move the definition of struct __sFILE into libc/stdio/local.h Once RELENG_8 is branched: e) Don asbestos underwear and re-arrange struct __sFILE to grow _file etc. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --dgjlcl3Tl+kb3YDk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHxQpN/opHv/APuIcRAgmnAKC6cMr+GWFK5J985GWWAkWv4CwsowCgjDr6 lpsxwQUgrmyup1dI4KTf5dI= =ei2f -----END PGP SIGNATURE----- --dgjlcl3Tl+kb3YDk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080227065925.GK83599>