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:
http://www.opengroup.org/onlinepubs/007908799/xsh/fseeko.html
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, since AC_SYS_LARGEFILE has never set _LARGEFILE_SOURCE 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 3.1.2.12 <unistd.h>
(from http://216.239.51.100/search?q=cache:Jvi-99KXhFgC:www.sas.com/standards/large.file/x_open.20Mar96.html+fseeko+large+file+summit&hl=cs&ie=UTF-8)
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
