Re: Bug#250086: extipl: please add amd64 support
Ed Cogburn <firstname.lastname@example.org> writes:
> On Monday 14 March 2005 5:05pm, Taketoshi Sano wrote:
>> Goswin von Brederlow <email@example.com> 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
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.