TT> That won't work, because glibc 2.0.7, which ships with Redhat 5.0,
TT> doesn't have lseek64. So if I adopted your suggestion, folks with
TT> RedHat 5.0 who tried recompile e2fsprogs would trash their > 2GB
TT> filesystems. Hence, I still have to test for the prototype.
NO, NO, NO! The prototype is the wrong way to test for a function.
The simple, easy, and reliable way with autoconf is:
AC_CHECK_FUNCS(llseek)
AC_CHECK_FUNCS(lseek64)
Which does a linkage test! This is totally reliable on both libc5 &
glibc 2.0.6. I just tried this.
It totally reliably _fails_ under glibc 2.0.6. That's because it has
llseek, but not the prototype for llseek. Here's the matrix:
libc5 glibc-2.0 glibc-2.1
has llseek_prototype yes no no
has llseek yes yes yes
has lseek64 no no yes
If you test for lseek64 under glibc-2.0.x, it will not exist, while
llseek does exist. However, this does not mean it's safe to use llseek;
under glibc-2.0, the prototype for llseek does not exist, even though
the function in the library does exist! That's why people's filesystems
were getting trashed.
My big complaint against the glibc developers was that when going
between libc5 and glibc-2.0, the prototype for llseek disappeared,
without making the llseek function go away. If they had made the llseek
function go away along with the prototype, claiming that llseek was "not
standard" (maybe, but strdup's not standard either, and we have it
declared in libc), things would have been OK.
You might want to add a check for a prototype in the header files,
since you seem to know how to do this hard and unreliable thing, to
see if you need to declare llseek, but otherwise I don't see the
point.
That's precisely why I need to do this test; to see if I need to declare
llseek. I only want to declare if I know that it is necessary, since
it's in general a bad idea to double-declare functions which are already
declared in the system header files (where they belong). Duplicating a
system header file can cause other problems.
Well it would be nice if there was a sanity check for large partitions
so your application doesn't fail when the offset is larger than lseek,
or llseek or in the futurer lseek64 can handle.
There would have been no problem handling it with llseek if it was
prototyped correctly. It was the lack of the prototype which caused the
problem, which is why I solved the problem by adding an autoconf check
for the existence of the prototype.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu