This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: using _FILE_OFFSET_BITS=64 with a non-gcc compiler
> > Of course it does. Every symbol defined in system headers which is in
> > the user namespace (and all these symbols are) must be defined or
> > reserved in the standard. Otherwise it's a violation.
>
> Are 'readdir64' and 'getrlimit64' defined or reserved in the standard?
>
> Are 'dirent64' and 'rlimit64' defined or reserved in the standard?
Neither, nor. However, that is precisely the reason why a system
header most not introduce a #define for readdir64. Looking at C99,
4p6, we see
# A conforming implementation may have extensions (including
# additional library functions), provided they do not alter the
# behavior of any strictly conforming program.
with a footnote saying
# This implies that a conforming implementation reserves no
# identifiers other than those explicitly reserved in this
# International Standard.
The standard *only* reserves the names defined in the headers, and
names starting with __ (etc.). Even though this is quoted from C,
Posix has a similar statement - it just extends the list of reserved
identifiers (through additional header files).
So readdir64 is *not* reserved by the standard. That means that any
program is free to use it in any way it wants. Thus
int dirent64;
#include <dirent.h>
int main(){
dirent64 = 1;
}
is a well-formed program which fails to compile under your proposed
implementation.
Regards,
Martin