Re: [PING][PATCH] Warn about using _ino_t without -D_FILE_OFFSET_BITS=64.

["Joseph S. Myers" <joseph at codesourcery dot com>]

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