This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Copy as much as you can during a 32-bit stat beforereturning EOVERFLOW?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library<libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Tue, 26 Feb 2013 23:04:58 +0000
- Subject: Re: [RFC] Copy as much as you can during a 32-bit stat beforereturning EOVERFLOW?
- References: <512D1335.1020704@redhat.com> <20130226210002.C598C2C07E@topped-with-meat.com>
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