Re: [PATCH] Deprecate 32-bit off_t support

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 4 Jan 2019, Siddhesh Poyarekar wrote:

> Wouldn't it be clearer to fix the 'future release' to a specific timeline,
> say, 2.31 (to give a year+ to change offending code) so that this doesn't
> sound like a vague threat and there's actually a time bound for people to work
> with?

There should be one or more releases with the default changed but the old 
API still available with -D_FILE_OFFSET_BITS=32, before any release with 
_FILE_OFFSET_BITS=32 no longer available and the old ABIs turned into 
compat symbols.  Giving concrete future release versions for a complicated 
change without patches in existence seems dubious.

Note 1: changing the default for user programs, without changing the mode 
used to build glibc and its tests, is easy.  Mike Frysinger posted patches 
in March 2014, and Paul Eggert did some investigation of the effects on 
the ABIs of libraries in a GNU/Linux distribution (many of which are in 
fact already built with _FILE_OFFSET_BITS=64).  Bug 13047.

Note 2: changing the mode used to build glibc itself, as required for 
eliminating the other mode as a supported API in the headers, is much more 
involved, because you need to avoid the header redirections affecting the 
compilation of all the functions for the 32-bit ABI, and keep all the old 
types and structures available in internal headers for building those 
functions although they'll no longer be accessible with installed headers.

Note 3: changing the default mode as used for building testcases (which 
might or might not be the same as the default used for building glibc 
itself) requires fixing the associated linknamespace issues by adding new 
public __*64 symbol names and using them instead of *64 in the header 
redirections (bug 14106).

Note 4: a change of default for building testcases would need to be 
accompanied by systematically making sure that all relevant interfaces are 
tested in all three cases (_FILE_OFFSET_BITS=32, _FILE_OFFSET_BITS=64 and 
the explicit *64 APIs).  Once _FILE_OFFSET_BITS=32 is no longer supported, 
the corresponding ABIs would still need to be tested (using 
compat_symbol_reference etc.) to make sure they continue to work, using 
the expected structure layouts and other types which would need to move to 
internal headers (and care is needed to verify in some automated way that 
the layouts put in internal headers really do match the existing ones in 
installed headers in all cases).

Note 5: presumably the change would also make the _FILE_OFFSET_BITS=64 C++ 
name mangling the default on 64-bit platforms where the C ABI doesn't 
change (see bug 15766), and, similarly, while both APIs are supported, 
-D_FILE_OFFSET_BITS=32 would result in the old mangling on 64-bit 
platforms (despite off_t still being 64-bit so the macro name / value 
being a bit misleading in that case).

Note 6: much the same would apply with struct stat layout on mips64 (n64 
ABI has stat and stat64 layouts different despite off_t being 64-bit by 
default, so the default struct stat layout would change to what's 
currently stat64 and _FILE_OFFSET_BITS=64 stat).

-- 
Joseph S. Myers
joseph@codesourcery.com