From owner-freebsd-arch@FreeBSD.ORG Fri Sep 28 22:52:43 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF66106566C for ; Fri, 28 Sep 2012 22:52:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 568C48FC0A for ; Fri, 28 Sep 2012 22:52:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B82BEB946 for ; Fri, 28 Sep 2012 18:52:42 -0400 (EDT) From: John Baldwin To: arch@freebsd.org Date: Fri, 28 Sep 2012 18:47:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201209281847.39663.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Sep 2012 18:52:42 -0400 (EDT) Cc: Subject: stdio and short file descriptors revisited X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 22:52:44 -0000 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 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