Ed Cogburn <[EMAIL PROTECTED]> writes:
> On Monday 14 March 2005 5:05pm, Taketoshi Sano wrote:
>> Hi.
>>
>> Goswin von Brederlow <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
