On Friday 31 October 2008 16:02:48 Kai Henningsen wrote:Am Fri, 24 Oct 2008 17:53:25 -0500
schrieb "Michael Kerrisk" <mtk.manpages@xxxxxxxxxxxxxx>:Hi Daniel,Actually, it's not inconsistent as described, though perhaps that is
On Thu, Oct 23, 2008 at 9:50 AM, Daniel Gollub <dgollub@xxxxxxx>
wrote:EINVAL bufsiz is not positive.The EINVAL error was added to man-pages-1.18 in 1997 (even though, as
you note, the type was "size_t"). I suspect (this was well before I
had any association with man-pages) that was done to reflect kernel
reality (since one could bypass glibc invoke the syscall directly),
but obviously it is inconsistent with the prototype.
unintentional. "Not positive" isn't the same as "negative", as zero
isn't positive either, and zero is certainly a possible value of an
unsigned type
True.
But there is still the problem for the ltp syscall test "readlink03", when using the glibc "readlink" interface, by calling readlink with a buffer size of "-1".
Calling "-1" seems to be a valid code/error-path in the linux syscall "readlink", since there is a check for less-equal zero.
But the less zero, condition can't be reached via the glibc "readlink" interface since this would cause fortify-check to fail (when buliding with -
D_FORITFY_SOURCE=2).
To "workaround" the fortify check, by not compiling the testcase with -
D_FORTIFY_SOURCE=2, or trying to test the linux readlink interface by calling directly syscall() in the testcase ... both suggestion are just workarounds - no real solutions.
We could also just remove the testcase of buffer size "-1".
The problem is still, how to test the "readlink" syscall in LTP?