svn commit: r211276 - head/lib/libc/net

[Kostik Belousov]

On Tue, Oct 05, 2010 at 12:30:02AM +0900, Hajimu UMEMOTO wrote:
> Hi,
> 
> >>>>> On Sun, 3 Oct 2010 21:49:26 +0300
> >>>>> Kostik Belousov <kostikbel at gmail.com> said:
> 
> kostikbel> I suspect there is some subtle issue with the commit present.
> kostikbel> When getprotobyname_r() is unable to find the protocol, it seems
> kostikbel> that established behaviour is to return 0 and set *protoent to NULL.
> 
> The behavior you mentioned is questionable to me.  Though I cannot
> find the manpage of getprotobyname_r(3), there is following
> description in the manpage of gethostbyname_r(3) on CentOS:
> 
> 	Glibc2 also has reentrant versions gethostbyname_r() and
> 	gethostbyname2_r().  These return 0 on success and non-zero on
> 	error.
> 
> When getprotobyname_r(3) is unable to find the protocol, it should be
> treated as error, IMHO.  My intention is that when getprotobyname_r(3)
> ends up with error but errno is zero, the return code should be
> non-zero (-1).
> 
> kostikbel> The getprotobyname_r() in HEAD and stable/8, when the protocol
> kostikbel> cannot be found, return whatever value was present in errno at the time
> kostikbel> of the call.
> 
> In anyway, errno should be cleared.  I've just committed to clear
> errno for each method dispatch.
> 
> kostikbel> When run with the argument "tcp1" on Linux, I get
> kostikbel> 	Res 0 errno 0 Success pres (nil)
> kostikbel> On the recent FreeBSD I get
> kostikbel> 	Res 25 errno 25 Inappropriate ioctl for device pres 0x0
> kostikbel> (ENOTTY is from stdio).
> 
> Now, it shows:
> 
> 	Res -1 errno 22 Unknown error: 0 pres 0x0
> 
> (When strerror(3) is called with 0 for its argument, it set errno to
> EINVAL.)

Yes, I saw that commit. And there is a software in wild that does expect
return value 0 and NULL returned pointer when protocol was not found,
as opposed to some processing error. The interpretation of non-zero
error code is "We did something wrong, or system configuration is wrong,
etc". While zero error code and NULL pointer is perceived as "Wrong
protocol name supplied".

Solaris uses different API, I think we better follow Linux if we
selected the Linux API variant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20101004/9967d87a/attachment.pgp