From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15809 invoked by alias); 26 Feb 2013 23:49:00 -0000 Received: (qmail 15791 invoked by uid 22791); 26 Feb 2013 23:48:59 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC2,RDNS_DYNAMIC,TVD_RCVD_IP X-Spam-Check-By: sourceware.org Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Feb 2013 23:48:53 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1UAUGP-0005N7-00; Tue, 26 Feb 2013 23:48:49 +0000 Date: Tue, 26 Feb 2013 23:49:00 -0000 To: Carlos O'Donell Cc: GNU C Library , libc-ports@sourceware.org Subject: Re: [RFC] Copy as much as you can during a 32-bit stat before returning EOVERFLOW? Message-ID: <20130226234849.GH20323@brightrain.aerifal.cx> References: <512D1335.1020704@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512D1335.1020704@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: Rich Felker Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00068.txt.bz2 On Tue, Feb 26, 2013 at 02:55:33PM -0500, Carlos O'Donell wrote: > Community, > > There are several filesystems which are going to be switching over > or already have switched over to unconditional 64-bit inodes and > file sizes. This means that the current crop of 32-bit applications > may not be able to run reliably on these filesystems since stat > may return EOVERFLOW for large values. Can we PLEASE reconsider the decision to keep supporting 32-bit off_t? If we're to the point where stat() *randomly* (from the application's and user's perspective) fails when compiled with 32-bit off_t, then I think such programs are just fundamentally broken now, and need to be deprecated. Despite the move to compile everythin with -D_FILE_OFFSET_BITS=64, last time I checked, Debian still has a number of packages which are compiled without it, and thus which might experience random breakage on newer filesystems. In my opinion, the migration path should be something like this: Stage 1: Change the default for _FILE_OFFSET_BITS to 64 on all targets, and make 32-bit off_t accessible only by explicitly requesting -D_FILE_OFFSET_BITS=32. This should help transition all the stragglers who are just straggling because they don't know better; the few who have fundamentally buggy code that's incompatible with 64-bit off_t can use the workaround (-D_FILE_OFFSET_BITS=32) until they get their acts together. Stage 2: Remove all 32-bit off_t infrastructure from the headers and leave the legacy 32-bit off_t symbols around only for use by already-linked applications. At this point, New symbol versions can be introduced for all of the functions (open, etc.) so that hacks remapping them to the nonconforming namespace names (open->open64, etc.) can be removed; legacy applications can get the legacy behavior based on the symbol version rather than the symbol name. This will also resolve the issue that glibc does not allow you to declare some of these functions yourself without including the associated header. I would be perfectly happy with stage 1 being made in the next release cycle and stafe 2 in the following release cycle, but if it would be more agreeable to wait 2 or more release cycles before stage 2, that's still much better than living with the current breakage indefinitely. Opinions? Rich