[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lseek64 () - More of a query than a true *BUG*...
From: |
Trevor van Bremen |
Subject: |
lseek64 () - More of a query than a true *BUG*... |
Date: |
Wed, 15 Oct 2003 00:45:53 -0400 |
Hiyaz,
I run Slackware-Linux (Version 8.1)
It's currently running with Linux Kernel 2.4.18
The included version of glibc in that version of Slackware is 2.2.5
Admittedly, that's all quite old (by OSS standards), but, I've also looked
at the Slackware 9.1 release which uses Kernel-2.4.22 and glibc-2.3.2 which
appears to have the same issue with llseek ().
The issue stems from the fact that the IA32 Linux Kernel is limited to only
returning 32 bit values from a system call.
(
In /usr/src/linux/arch/i386/kernel/entry.S it shows that only the EAX
register is returned from *ANY* system call
)
However, the lseek64 () function, when called from within a 'C' program is
*SUPPOSED* to return the new 64-bit offset into the file.
In glibc-2.3.2 for Linux IA32, the lseek64 () function is implemented as a
wrapper around the llseek system call in Linux.
(
See sysdeps/unix/sysv/linux/llseek.c in glibc source
)
However, I believe the actual implementation specifics are incorrect in this
instance... Technically, the llseek system call in IA32-Linux is also
incorrectly implemented in that it should either return 0 (SUCCESS) or -1
(FAILURE). What it *DOES* return is the lower 32 bits of the new offset.
The glibc-2.3.2 source that I am looking at actually *USES* this partial
value as the return value from lseek64 (). In reality, it *SHOULD* be
returning the value in retval (being the FULL 64 bit output of the system
call)
Note that if SINGLE_THREAD_P was not defined as 1, I believe the function
would function differently.
"
Description: Binary data
- lseek64 () - More of a query than a true *BUG*...,
Trevor van Bremen <=