Petr Vandrovec schrieb:
On 17 Mar 03 at 15:08, Guido Draheim wrote:
Petr Vandrovec schrieb: So, it boils down that one might need to choose from: (a) #error out when the user did ask for OFFSET64 but did not ask for LARGEFILE. The OFFSET64 implies LFS extensions. (b) ignore OFFSET64 and leave sizeof(off_t) as sizeof(long), since the sources did not say they are LARGEFILE ready but some other parts have said they are ready for loff. This is plain wrong for its problems in mixing libraries and their headers. (c) silently enable LARGEFILE when OFFSET64 is seen and provide the user with an fseeko that maps to fseeko64 to avoid callframe-mismatch. That's what I'm asking for.
You get warning. In C++ you get error. If you ignore warnings, it is your problem...
You only get warnings when using -Wall or similar. The C language is otherwise fine with non-prototyped symbols. No need to ignore them since they do not get printed unless asked for.
So, after that long text, a question to you: what's wrong the implication OFFSET64 -> LARGEFILE.
That you define fseeko/ftello even if you did not asked for them. You are saying to the library that your code is not UNIX98 aware and that your code does not want fseeko/ftello. So you get exactly you asked for. Either declare your code as UNIX98 aware, or as wanting fseeko/ftello, and all your troubles will disappear.
The library is both, it can work in pre-unix98 system and those after it. I don't argue that I can make the problems disappear (I have already done so), it's that other developers will easily produce incorrect code due to problems in glibc headers, and there is a good chance they won't notice. The compiler links to a non-prototyped symbol, which is okay for C, and everything works smoothly after it - as long as you do not get into bigger sizes of your database of course, which makes the lossage a bit more frightening.
C library must not declare symbols without leading __ just itself, as it shares namespace with app, and even if app is built with LARGEFILE64_SOURCE, it can still expect to have its own fseeko function which does something completely different.
what? doh! how so?
You can read archives - while googling for LFS text I found quite a lot 'ac_sys_largefile' discussions, all comming down to the "Use proper #define for your code" and do not ignore warnings.
Most do in fact relate to problems of ac_sys_largefile as some platforms do not quite get into largefile mode for some reason. It might be that the fixup for the glibc "pecularity" should be done in ac_sys_largefile where one could add the implication of OFFSET64 -> LARGEFILE. Actually, the macro is named _largefile, and not offset64, i.e. when LFS is available, try to get it into 64bit mode.
After looking a bit around, I see what you mean with calling the sources lfs-aware through _largefile_source. That doesn't get us rid of that other problem: the callframe-mismatch.
Since I've been looking a bit into sources, I did notice another pecularity of glibc headers: fseeko will be defined for non-gcc compilers even without _largefile_source, right? See here, in features.h:
/* If we don't have __REDIRECT, prototypes will be missing if __USE_FILE_OFFSET64 but not __USE_LARGEFILE[64]. */ # if defined __USE_FILE_OFFSET64 && !defined __REDIRECT # define __USE_LARGEFILE 1 # define __USE_LARGEFILE64 1 # endif
Interestingly, it seems the comment and implementation disagree. Shouldn't that be:
/* If we don't have __REDIRECT, prototypes will be made available if __USE_FILE_OFFSET64, and independent of prior __USE_LARGEFILE[64]. */ # if defined __USE_FILE_OFFSET64 && !defined __REDIRECT # define __USE_LARGEFILE 1 # define __USE_LARGEFILE64 1 # endif
