Bug 14106 - _FILE_OFFSET_BITS=64 goes outside standard namespace
Summary: _FILE_OFFSET_BITS=64 goes outside standard namespace
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.15
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-05-14 10:50 UTC by Joseph Myers
Modified: 2020-02-17 07:11 UTC (History)
3 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Myers 2012-05-14 10:50:46 UTC
Building with -D_FILE_OFFSET_BITS=64 uses names that should be in the user's namespace.  For example,

#include <stdio.h>
#include <stdlib.h>

void fopen64 (void) { abort (); }

main (void)
  fopen ("/dev/null", "r");
  return 0;

built with -std=c99 -D_FILE_OFFSET_BITS=64 on x86 aborts.

All the function redirects for _FILE_OFFSET_BITS=64 should be to functions in the implementation namespace.  This applies to POSIX interfaces as well as to ISO C ones.
Comment 1 Rich Felker 2012-05-14 12:39:41 UTC
This issue has been bothering me for a long time too, but I never thought to report it. The only solution I see is to rename all the *64 functions to __*64 and update the headers accordingly. Of course aliases would need to be kept with the old names, and _LARGEFILE64_SOURCE would need to expose the old names. Solving the problem also has the unfortunate consequence that newly-linked binaries will depend on a new glibc even if they otherwise would have worked with very old versions.

Nonetheless, I agree that something should be done about this bug. Using _FILE_OFFSET_BITS=64 is the only viable configuration on a modern system. (A mixed system with some binaries compiled with 32-bit offsets and others with 64-bit offsets has dangerous issues with file descriptor inheritance; see bug #13047.) And it seems a real shame for the only viable configuration to be non-conformant in this regard.
Comment 2 joseph@codesourcery.com 2012-05-14 13:01:44 UTC
On Mon, 14 May 2012, bugdal at aerifal dot cx wrote:

> This issue has been bothering me for a long time too, but I never thought to
> report it.

If you have any issues with glibc that can be represented as well-defined 
bugs - specific deficiencies for which it can be clearly assessed whether 
they have been fixed - and they don't have currently open bugs, please 
open (or reopen) bugs for them.  It doesn't matter how minor or obscure or 
hard to fix they are, we should track bugs in the bug database.  They may 
not be fixed particularly quickly - the existing bug backlog may take 
person-years of work across many people to deal with - but they should be 
filed so they are visible to people looking for bugs to fix.

(More open-ended projects for enhancement that don't represent a 
well-defined defect in current glibc may better go on the wiki than in 
Bugzilla; there are "Project TODO" and "Project Wishlist by Developer" 
sections there linking to pages with various suggestions.)