This is the mail archive of the
mailing list for the libc-ports project.
Re: [RFC] Copy as much as you can during a 32-bit stat before returning EOVERFLOW?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, libc-ports at sourceware dot org
- Date: Wed, 27 Feb 2013 14:26:34 -0500
- Subject: Re: [RFC] Copy as much as you can during a 32-bit stat before returning EOVERFLOW?
- References: <512D1335.firstname.lastname@example.org> <20130226210002.C598C2C07E@topped-with-meat.com>
On 02/26/2013 04:00 PM, 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?
> 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.
A given users needs are far more focused. In practice they want to move
to a newer distribution or filesystem and keep down the cost of the
upgrade while incrementally fixing applications.
> I don't see any defensible rationale for putting such a change into
I agree. I didn't want to colour the conversation with my initial opinion,
but it seems like everyone is pretty well agreed that the change would
complicate the API without enough gain.