This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Deprecate 32-bit off_t support
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
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