PATCH: set_thread_buffer fixed

At 10:43 AM 05/06/2001 +0200, you wrote:
>> This calls fails because glibc detects that the value at (esp+28)
>> is different of 0 - the real system call is never done, with your
>> test app and Wine.
>>Well, note that the second version is only pushing a 32bit offset, so
>mmap64 accesses random stack space!
Yes :-/
<snip>
>Yes, check the sys/mman.h header, it should have __off64_t as argument
>to the mmap ... asm("mmap64") not __off_t.
Yes, it is __off_t and that is the problem; but how this header has come to
be in this
state is part of what I don't understand. It's marked as part of the glibc,
but there
is nothing like it in the glibc source that I used to compile. The mman.h in
my glibc
source is much shorter and the declaration of mmap64 seems correct.
I guess that the file in my /usr/include/sys/mman.h is a generated file.
I don't even want to count the number of 'mman.h' files on my system :-/
>So I think I can use this test program as check for mmap64 brokeness...
Btw, the reference on large files
http://www.suse.de/~aj/linux_lfs.html
says that locking will never be supported on 64 bits files with glibc 2.1.3 so
I don't see why it's necessary to support this case.
Gerard