This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Copy as much as you can during a 32-bit stat before returningEOVERFLOW?
- From: Roland McGrath <roland at hack dot frob dot com>
- 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 13:00:02 -0800 (PST)
- Subject: Re: [RFC] Copy as much as you can during a 32-bit stat before returningEOVERFLOW?
- References: <512D1335.firstname.lastname@example.org>
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
I don't see any defensible rationale for putting such a change into