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

[Zack Weinberg <zackw at panix dot com>]

On 08/18/2016 03:36 PM, Paul Eggert wrote:
> Zack Weinberg wrote:
>> 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.
> 
> As I understand it, most (all important?) such libraries are already
> compiled with _FILE_OFFSET_BITS=64 anyway, so their ABIs wouldn't break.

I'd feel a lot safer about changing the default if we had some way of
tagging object files and shared libraries so that _FILE_OFFSET_BITS=32
and _FILE_OFFSET_BITS=64 code could not be combined.  Do we already have
that?  It seems like something that could probably be done with existing
object-annotation goo, if we don't.

> How about if we start the transition by deprecating the use of 32-bit
> off_t in user or library code on platforms with 32-bit long? The
> attached patch plus lots of similar patches, say (this is just a
> sketch). Really, it's long since time that file offsets were 64 bits.

I'd support this patch (better with __attribute_deprecated_msg__() and
an explanation that it's not off_t that's deprecated, it's *32-bit* off_t).

zw