From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15543 invoked by alias); 26 Feb 2013 21:00:15 -0000 Received: (qmail 15492 invoked by uid 22791); 26 Feb 2013 21:00:10 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Feb 2013 21:00:04 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id C598C2C07E; Tue, 26 Feb 2013 13:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath 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? In-Reply-To: Carlos O'Donell's message of Tuesday, 26 February 2013 14:55:33 -0500 <512D1335.1020704@redhat.com> References: <512D1335.1020704@redhat.com> Message-Id: <20130226210002.C598C2C07E@topped-with-meat.com> Date: Tue, 26 Feb 2013 21:00:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=LYSvtFvi c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=8O8SP-7CSg8A:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=R0K8r3JO6igA:10 a=YkNRPXAsxEJT9HbGF3QA:9 a=CjuIK1q_8ugA:10 X-IsSubscribed: yes 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/msg00065.txt.bz2 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? It may seem at first blush that the change would be simpler in complex programs. But, in fact, to be robust when using older libcs a program would have to do something very special to distinguish a library call (new-style) that delivered some truncated values from one (old-style) that delivered some or all uninitialized fields. Performance concerns aside, the real cost of this is making the API more arcane. It's a straightforward rule today that calls that fail leave any result parameters in an undefined state and programs must not assume anything about those bits of memory after a failing call. There are some exceptions such as nanosleep's EINTR case, but those are very few and are well-specified in POSIX. Old programs wanting something like you suggest can easily get it from a wrapper function something_stat supplied in some separate library (either an actual library or an informal one like gnulib) that calls stat64 and converts to the old format with the EOVERFLOW semantics you describe. I don't see any defensible rationale for putting such a change into libc. Thanks, Roland