> That will work in theory, but your test hard coded glibc version
> numbers, which is a really bad idea. What if in the future some future
> version of glibc drops lseek64, and so we fall back to the usable_llseek
> test, but the __GLIBC_MINOR__ version is no longer zero?
Why should this happen? lseek64 is a standard function.
> Then we'll be screwed once again. Perhaps you can argue that you or
> future glibc maintainers won't do this because you it would screw
> applications; but if that was the case, why didn't you keep the
> llseek prototype?
Because it's no standard function.
> In fact, when I get around to adding support for lseek64, I'll
> probably put a prototype on lseek64 for the same reason, in case
> future glibc maintainers decide to move the prototype to some other
> header file just because some standard body decided to make the
> change, and they decide that standards were more important than
> compatibility.
You're acting childish, really. Even if for some unknown reason the
standards should dictate to have the declaration in a different file
it will also provide for the next N revisions the declaration in the
old place. You simply cannot compare the total ommission of the
llseek prototype with the. The glibc API is intended to be different
from the libc5 API. The changes are not made because some standards
demands them but instead because the libc5 made it wrong and we
haven't made this error while developing glibc in parallel. It
becomes time to remove all the #ifdef __linux__ from the sources and
use the code which all platforms can use.
-- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu