Re: Bug#250086: extipl: please add amd64 support
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.
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.
Reply to: