lseek64 () - More of a query than a true *BUG*...

[Trevor van Bremen]

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