[PING][PATCH] Warn about using _ino_t without -D_FILE_OFFSET_BITS=64.
Joseph S. Myers
joseph@codesourcery.com
Fri Mar 21 13:11:00 GMT 2014
On Fri, 21 Mar 2014, Ondrej Bilka wrote:
> ping
Scattergun patches changing a random header with a random deprecation (not
even the header most likely to be used to get the type in question, which
is sys/types.h not dirent.h) make no sense here.
The following kinds of patches make sense here as incremental improvements
(they are not necessarily needed for a change in the default, just
somewhat vaguely related, but they also have self-contained justification
independent of any such change or deprecation): (this is not an exhaustive
list)
* Adding *64 versions of interfaces without them (at least fts).
* Refining conditions used in headers (at least fts.h) to reject use in a
particular _FILE_OFFSET_BITS mode. The conditions need to be
conservatively safe. The relevant conditions for fts.h are, I think, that
ino_t and struct stat match between the two interfaces. I don't think any
form of static assertion is needed there; bits/typesizes.h has a macro
__INO_T_MATCHES_INO64_T, and a header could be added that defines a macro
for whether stat and stat64 match (probably with a generic version
defining it if __LP64__, and a MIPS GNU/Linux version that never defines
it, but anyone implementing this should check all systems carefully to
confirm this). Of course, if the previous point were implemented, this
would become irrelevant.
* Fixing the ISO C / POSIX namespace issues for _FILE_OFFSET_BITS=64,
using existing __*64 symbols where already exported at a public symbol
version or adding new ones at a new symbol version if not (bug 14106).
* Stopping _FILE_OFFSET_BITS=64 affecting the C++ ABI on 64-bit
architectures (bug 15766) - although inevitably that could break things
for some existing C++ binaries (but sometimes such mangling breakage seems
unavoidable, e.g. the removal of the "siginfo" tag from siginfo_t).
* Where code internally in glibc and the miscellaneous programs it
installs uses non-large-files interfaces such as fopen or __open, making
it use the versions supporting large files instead.
But for any change to the default or deprecation, we need an in-depth
analysis showing what the effects would be in practice. For all the
library headers in a large GNU/Linux distribution, how many use any
affected type in an ABI, and what settings are those libraries built with?
For all the program and library binaries in a large distribution, how many
use the _FILE_OFFSET_BITS=32 interfaces, how many use the
_FILE_OFFSET_BITS=64 interfaces, how many use interfaces such as fseek and
ftell that are implicitly unsafe in the _FILE_OFFSET_BITS=64 context and
need changing to fseeko / ftello to work reliably in that context? Post
the scripts used so other distributions can adapt them to tell what's
affected in their distributions. If you rebuild a distribution with a
changed default, what builds break?
In principle I think a change to the default is likely to be a good idea,
but first we need a clear understanding of the extent of its impact on
ABIs of non-glibc libraries, and tools that distributors can use to work
out what libraries in their distributions are affected and plan ABI
transitions as needed.
(I'm not asking for a detailed analysis of each affected library, but
lists like "these 50 library packages are affected out of 1000 in
distribution X" would help indicate the scale of the issue. And some
examples for individual cases from distributors, "this is how we'd handle
the transition for library Y so that binaries users built with the old
version of library Y continue to work correctly", would help as well -
such a change means a large whole-system transition that distributors need
to be on-board with to avoid breaking things for their users, or breaking
cross-distribution binary compatibility as far as possible. Details
agreed between distributors of how to handle particular libraries might
then go on a wiki page somewhere in the interests of cross-distribution
binary compatibility.)
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list