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 before returningEOVERFLOW?
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, libc-ports at sourceware dot org
- Date: Tue, 26 Feb 2013 12:37:08 -0800
- Subject: Re: [RFC] Copy as much as you can during a 32-bit stat before returningEOVERFLOW?
- References: <512D1335.1020704@redhat.com>
On 02/26/13 11:55, Carlos O'Donell wrote:> Community,
> The correct solution is going to take time to implement
Don't the proposed patches to xstatconv.c etc. slow down glibc
slightly for the normal (successful) case? That's a minus.
Here's a different idea: enable wide ino_t, time_t, etc. if
_FILE_OFFSET_BITS is 64. This would require zero changes to
applications that are portable and largefile aware, as they
already define _FILE_OFFSET_BITS. And even for nonportable
applications, compiling with -D_FILE_OFFSET_BITS=64 (and fixing any
resulting porting glitches) should take less time and should be safer
than modifying the applications to make the unportable assumption that a
struct stat is filled in if errno == EOVERFLOW.
A more-conservative variant of this idea would establish a new symbol
that means "use wide-enough values for all file-related types".
-D_WIDE_FILE_TYPES, say, would use wide types for off_t, time_t,
ino_t, etc. Portable application developers could modify their code
to set this symbol as well as setting _FILE_OFFSET_BITS, which is a
bit of a hassle, but I've seen worse (e.g., Mac OS X uses
_DARWIN_USE_64_BIT_INODE to select 64-bit inodes, but that's all it
does -- yuck).