This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]