[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ac_sys_largefile / fseeko problem

From: Guido Draheim
Subject: Re: ac_sys_largefile / fseeko problem
Date: Mon, 17 Mar 2003 16:08:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]