recvfrom/recvmsg

recvfrom/recvmsg

[Paul Larson]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]


I was looking through the ltp test recvfrom01 and saw that test #4 is
failing where it did not used to fail.  I think the test program is
partially at fault here since it was expecting it to pass when you call
recvfrom with fromlen == -1.

Right now (2.5.46-bk current) I'm getting -1, errno 22 returned, but in
2.5.46 it was passing without error.  Was this change intentional
(probably) and is that the correct errno to return.  I checked SuS, but
I don't see anything related to that exact condition.

There is another test in the same program that also looks like it should
be failing.  Recvfrom, testcase 3 tries to do a recvfrom with (struct
sockaddr *)-1 passed as the from buffer.  Right now, it is passing
without an error, but that doesn't seem correct.

The same exact situation happens in recvmsg01.

Thanks,
Paul Larson


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]

Re: recvfrom/recvmsg

[David S. Miller]

   From: Paul Larson <plars@linuxtestproject.org>
   Date: 08 Nov 2002 15:59:24 -0600
   
   Right now (2.5.46-bk current) I'm getting -1, errno 22 returned, but in
   2.5.46 it was passing without error.  Was this change intentional
   (probably) and is that the correct errno to return.  I checked SuS, but
   I don't see anything related to that exact condition.
   
No idea.  But -1 is invalid.

   There is another test in the same program that also looks like it should
   be failing.  Recvfrom, testcase 3 tries to do a recvfrom with (struct
   sockaddr *)-1 passed as the from buffer.  Right now, it is passing
   without an error, but that doesn't seem correct.

If namelen is zero, no attempt is made to access the sockaddr pointer.
Returning -EFAULT is always variable and no system call can guarentee
to return this so no test should require it to be returned.