[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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: