> 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.
It's as standard as strdup is (Solaris has llseek, for example), and yet
you kept support for strdup and not llseek. Why? From where I sit, the
decision about llseek was completely capricious and arbitrary, and
that's what bothers me so much about it.
And even if I grant your explanation for removing it, you should have
removed it completely. I heard the excuse of ABI compatibility, but ABI
compatibility between libc5 and glibc doesn't exist anyway. Keeping the
llseek funtion while removing the prototype did a lot of harm, and as
far as I can tell, it had little to no benefit.
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...
When llseek was first added to libc, the open64/lseek64 interfaces
weren't standardized yet. llseek was what was the defacto standard, and
it's what programs like e2fsprogs used if they wanted a 64-bit lseek.
So it's hardly a matter of "wrong", but it that was simply a legacy,
de-facto interface of the time. (By the way, Solaris 2.5 still doesn't
have the open64/lseek64 interface, but it does have llseek.)
Breaking legacy, de-facto standards in the name of standards is really
the heart of the disagrement. I believe it's wrong, and it's clear you
don't care.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu