Re: [RFC] Copy as much as you can during a 32-bit stat before returningEOVERFLOW?

[Roland McGrath <roland at hack dot frob dot com>]

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