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. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
