[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 15:08:39 +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 12:02, Guido Draheim wrote:

Petr Vandrovec schrieb:

On 17 Mar 03 at 11:33, Guido Draheim wrote:

Personally, I think it would be the best to simply
add a global change in features.h

What about reading LFS standard: if _LARGEFILE_SOURCE is not
defined, neither fseeko nor fseeko64 do exist. Take it up with standard authors, not with glibc guys.

I can take it up with either guys ;-)

Firstly, SUS2/UNIX98 lists fseeko _without_ a requirement
on some _LARGEFILE_SOURCE to exist. Read the given standard
page reference if you don't believe me:

If you'll define _XOPEN_SOURCE=500 (to get SUSv2), you get _LARGEFILE_SOURCE, so I see no problem...
Secondly, I'm cc'ing autoconf ML exactly for that reason,
even that LFS specs mandate that it should be the
primary selector to enable LFS pieces. I guess that you
did guess a requirement for fseeko from that fact.

3.3 Accessing the Extensions to the SUS
3.3.1 Compilation Environment - Visibility of Additions to the API
Application which define the macro _LARGEFILE_SOURCE to be 1 before
inclusion of any header will enable at least the functionality
described ni "2.0 Change to the Single UNIX Specification" on implementations
that support these features. Implementatons that support these features
will define _LFS_LARGEFILE to be 1 in <unistd.h>, as described in <unistd.h>


So you are either operating in pre-SUSv2 environment, where above
applies and you must define _LARGEFILE_SOURCE, or you operate in
post SuSv2 environment, where you must set _XOPEN_SOURCE=500.

Or, you should build all apps with _GNU_SOURCE, which gives you complete
API as exported by glibc library.

Unfortunately there is no way how to prevent you from using fseeko
symbol from binary if you ignored compilation warnings (except naming
fseeko differently, but almost all glibc functions are available only
after defining certain defines, so this would create only nightmare).

So, here we get to the real thing. Let's see if I can make the
problem understood that is about it.

My app shall use large-off_t as soon as it is available. It has #ifdef's
to allow the sources to compile in a pre-off_t environment as well, using
a local typedef to `long` when no off_t is there and picking up pre-off_t
fseek(). These are the only #def's needed, all other filesystem-related
calls can stay as is.

This is due to unix98 headers with largefile-sensitive off_t type to
have some builtin magic to push the old filesystem-related calls into
the 64bit world. The sources can still use lseek, truncate, stat,
pread and whatever, but the callframe layout changes magically. And
glibc uses REDIRECT to reach out to a dual-mode-off_t libc library,
linking source-level open() to asm open64.

This magic has one exception: fseek and ftell. These can not be just
forwarded into replacing the traditinoal `long` with an `off_t` kind
of a prototype (as they have not been declared in unix95 with a off_t
type). That's what triggered the invention of fseeko as a replacement
and which allows to pick up the magic for shapeshifting off_t type - in
some it may call with a 32bit-off_t callframe and along with other
#defs it gets a 64bit-off_t callframe.

The glibc headers choose to use off_t universally to declare
the prototypes of filesystem-related functions (no #ifdef LARGEFILE
to use `long` instead). The only exception is fseek, and it does
not get its cousin fseeko along. We have the problem that glibc
declares with off_t according to unix95 specs but does not add
the single unix98 extension fseeko which is only added as it
was forgotten back then. (well, actually fseek is on a different
standards body, but the problem of fseek-calls with that opaque
data type off_t could have been grasped back then, but they were
not an issue since always sizeof(long) == sizeof(off_t)).

As a factual moment, fseeko and fseek are call-compatible when
off_t is left in traditional `long` mode on legacy system. There
wouldn't be much a problem when glibc headers would just
#define fseeko fseek when no OFFSET64 is specified, right. Well,
actually that's what my app does when no fseeko seems to exist.
The `off_t` is a `long` anyway in such a traditional pre-unix98
environment, AC_TYPE_OFF_T points to this tradition as well.

And that's no problem really. Just like AC_C_CONST, AC_C_INLINE,
AC_C_RESTRICT, we can have valid fallbacks for symbols that
were introduced later. The fseeko call will match with the
fseek callframe layout. With one exception: when a user app
has asked for a 64bit off_t, and the headers are not quite
intelligent enough to understand such a thing is only ever
possible when LFS transitional API is there, since otherwise
there couldn't be a shapeshifting off_t.

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.

So, after that long text, a question to you: what's wrong
the implication OFFSET64 -> LARGEFILE.

-- cheers, guido

reply via email to

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