Subject: Re: getnameinfo(3) behavior on short string region

From: David Borman <[email-masked]>
Date: Tue, 2 Nov 1999 22:29:21 -0600 (CST)

> Subject: getnameinfo(3) behavior on short string region
> From: [email-masked]
> Date: Wed, 03 Nov 1999 12:02:22 +0900
>
>
> 	Hello, if you do the following:
>
> 	char h[2];
> 	getnameinfo(sa, sa->sa_len, h, sizeof(h), NULL, 0, NI_NUMERICHOST)
>
> 	getnameinfo from NRL code fills in 1 letter into the buffer (h)
> 	and returns without error. getnameinfo from KAME code will raise error
> 	(by returning non-zero).  Which behavior is more
> 	correct/natural/desired?  There's nothing said in RFC2553.

On page 30, RFC2553 says:

   The caller specifies not to return either string by providing a zero
   value for the hostlen or servlen arguments.  Otherwise, the caller
   must provide buffers large enough to hold the nodename and the
   service name, including the terminating null characters.

Even though it's not what I implemented when I first wrote a getnameinfo()
function, having thought about it I'd read this part as saying that if
the buffer is too small, returning an error is the right thing.  Silently
truncating the numeric string could be dangerous, especially if you wind up
dropping just the last digit, since both could be valid IP addresses.

E.g, if you have a 12 byte buffer and you are using the address for
ftp.ietf.org, 132.151.1.19, with truncation (11 bytes plus a NULL)
you'd get "132.151.1.1" instead, which would not be good.

			-David Borman, [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Thu, 04 Nov 1999 09:15:03 -0500

Itojun,

Per Daves response attached.

I believe Dave's response is correct (thx Dave).  But I want to point
out that we (the IETF) have no control over getnameinfo or getaddrinfo
it is a POSIX and XNET issue.  This is why we did not touch nor
extend these APIs from Info rfc2133 to rfc2553.  I suggest if you or
others see behaviors in these APIs which have errors to contact your XNET
representative or IEEE representative on the POSIX committee.  Clearly
telling us on this list the error exists is useful, but we can't do
anything here about it.  Just like if XNET finds errors in UDP they
can't do anything about it and must come to the IETF.

This is one reason (and I have many) I will not use these APIs but
prefer getipnodebyname and friends.   Note this is a personal choice as
a programmer and not the view of my company or necessarily the views of
my colleagues who work on IPv6 with me.

/jim