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 -- 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
