On Thu, Aug 18, 2016 at 1:52 PM, Christoph Hellwig <hch@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
