[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ac_sys_largefile / fseeko problem
From: |
Petr Vandrovec |
Subject: |
Re: ac_sys_largefile / fseeko problem |
Date: |
Mon, 17 Mar 2003 15:23:02 +0100 |
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...
> 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.
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.
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.
Petr Vandrovec