Re: [Linux PATCH] fcntl: add new F_OFD_*32 constants and handle them appropriately

[Zack Weinberg <zackw at panix dot com>]

On Thu, Aug 18, 2016 at 1:52 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Aug 18, 2016 at 10:46:07AM -0700, Mike Frysinger wrote:
>> there's no need to be so dramatic here.  glibc didn't write the LFS logic
>> for fun, and hasn't maintained it out of laziness.  in fact, the code is
>> non-trivial to get right.
>
> It hasn't maintained it out of lazyness, but out of stupidity - it's been
> 20 years overdue to get rid of supporting non-LFS for _new code_.

Please say concretely what you mean by "get rid of supporting non-LFS
for new code".  I can think of only two possibilities, both with
severe negative side effects.

We could change the libc headers used on old-ILP32 ABIs so that
_FILE_OFFSET_BITS=64 is defined by default (matching the LP64-ABI
headers).  This would break the ABI of every shared library that
exports a structure (transitively) containing a field of type off_t,
ino_t, fsblkcnt_t, fsfilcnt_t, or rlim_t.  It would also break
non-LFS-safe programs upon recompilation, although they could still be
recompiled with -D_FILE_OFFSET_BITS=32.  This latter breakage could
well be silent, going unnoticed until someone actually tries to use
the program with a very large file -- and such bugs can and have been
security-critical.  So by me this is already a bad plan.

Or we could go even further and remove all modes but
_FILE_OFFSET_BITS=64 from the libc headers, breaking non-LFS-safe
programs upon recompilation with no quick fix; that seems like an even
worse plan.

But perhaps you have something else in mind?

zw