From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21365 invoked by alias); 26 Feb 2013 23:05:10 -0000 Received: (qmail 21338 invoked by uid 22791); 26 Feb 2013 23:05:09 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Feb 2013 23:05:03 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UATa1-0005Mm-Qu from joseph_myers@mentor.com ; Tue, 26 Feb 2013 15:05:01 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Feb 2013 15:05:01 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 26 Feb 2013 23:04:59 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1UATZy-0000NJ-77; Tue, 26 Feb 2013 23:04:58 +0000 Date: Tue, 26 Feb 2013 23:05:00 -0000 From: "Joseph S. Myers" To: Roland McGrath CC: Carlos O'Donell , GNU C Library , Subject: Re: [RFC] Copy as much as you can during a 32-bit stat before returning EOVERFLOW? In-Reply-To: <20130226210002.C598C2C07E@topped-with-meat.com> Message-ID: References: <512D1335.1020704@redhat.com> <20130226210002.C598C2C07E@topped-with-meat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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/msg00067.txt.bz2 On Tue, 26 Feb 2013, Roland McGrath wrote: > The argument in favor of this API change seems quite thin. An old > program will have to be modified to accept EOVERFLOW failures, so why > not modify it to use *64 interfaces or -D_FILE_OFFSET_BITS=64 instead? Agreed. _FILE_OFFSET_BITS changes can be fiddly when a library's interface involves off_t or other affected types, but I'd expect changing each program to handle EOVERFLOW specially to be much more fiddly and fragile than a library ABI transition for libraries whose interfaces involve affected types - even though changing _FILE_OFFSET_BITS may also involve reviewing applications for cases where types such as "int" or "long" or associated printf formats are used to store values that may no longer fit in those types. (Where a library's interface depends on _FILE_OFFSET_BITS, I'd suggest a conditional #error in the library's headers to make sure that applications built with the library are using the same setting of _FILE_OFFSET_BITS.) -- Joseph S. Myers joseph@codesourcery.com