This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/2] Squashing long inodes.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Denis Obrezkov <reprofy at etersoft dot ru>, libc-alpha at sourceware dot org
- Date: Wed, 5 Mar 2014 13:35:07 -0500
- Subject: Re: [PATCH 0/2] Squashing long inodes.
- Authentication-results: sourceware.org; auth=none
- References: <1393521776-1102-1-git-send-email-reprofy at etersoft dot ru> <53104E9A dot 3040706 at redhat dot com> <5310E3B9 dot 8000406 at redhat dot com> <80fd9464ba8db600f50871cb27f8d422 at office dot etersoft dot ru> <53176AF9 dot 9080700 at cs dot ucla dot edu>
On Wed, Mar 05, 2014 at 10:20:41AM -0800, Paul Eggert wrote:
> On 03/05/2014 05:32 AM, Denis Obrezkov wrote:
> >we have some legacy programs which couldn't be recompiled at all
>
> Which are those? Can you give an example?
> >
> >and programs which couldn't be recompiled with this flag due to their
> >nature(mixing 32bit and 64bit things will cause undefined behavior).
>
> That's a problem already. You can't reliably mix code compiled with
> different settings of FILE_OFFSET_BITS. We already expose both
> ABIs, and I don't see why the ABI issue would be made worse (or
> better) if we merely changed the default.
Indeed it would be better because there would be less mixing. Rather
than having a large number of mismatches in application and
third-party library code due merely to folks *forgetting* to add
-D_FILE_OFFSET_BITS=64 or not even knowing they should be doing it, we
would only have a few mismatches left where -D_FILE_OFFSET_BITS=32 is
being set explicitly.
Personally I would love to see that phased out too, over a couple
release cycles. In the long term, the legacy symbols could be left
usable only by existing binaries, with no way to build new binaries
using them, and eventually this whole mess could be relegated to the
history books.
Rich