Re: Bug#250086: extipl: please add amd64 support
Ed Cogburn <edcogburn@hotpop.com> writes:
> On Monday 14 March 2005 5:05pm, Taketoshi Sano wrote:
>> Hi.
>>
>> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>> > Just plain lseek will do. With _FILE_OFFSET_BITS=64 that is all you
>> > need. I don't see the point of using the lseek64 alias.
>>
>> I don't know much about that. My experience told me
>> that libc5 system had llseek, but glibc system don't.
>> And _llseek has just worked on both of them.
>>
>> If you know much about 64bit file access, then please
>> let me know, what point do you see of using
>> "just plain lseek and _FILE_OFFSET_BITS=64".
>> And, I want to know from which version of glibc
>> we can use it safely (or can we use it on libc5 too ?)
>>
>> It will help me to explain this to the upstream.
>
>
> FYI, from glibc's info docs:
>
>
> 'When the source file is compiled with `_FILE_OFFSET_BITS == 64' the `lseek'
> function is in fact `lseek64' and the type `off_t' has 64 bits which makes it
> possible to handle files up to 2^63 bytes in length.'
>
>
> I believe that define is for building the libc library, not a user program, so
> if the system has a libc with Large File Support (defined as being compiled
> with `_FILE_OFFSET_BITS == 64' I assume), then a user app should only need to
> use lseek and off_t, and the right lseek function will be used by the
> library.
No, the glibc has both the 32bit and 64bit functions and several
defines can be used to tell the headers which ones the source expects
or can handle.
> I ran into a similar situation with stat/stat64 with an old glibc that did not
> transparently switch functions (on my system at least) as it claimed at the
> time. AFAICT, it does so now.
>
> PS, FWIW: '_lseek' or '_llseek' are not listed anywhere in glibc 2.3.2's
> info docs' function index. If its still there somewhere its probably only
> for backwards compatibility, and AFAIK we're supposed to be using lseek now.
_ are private functions.
MfG
Goswin
Reply to: