problem report bin/157732

[Christopher J. Ruwe]

> > 2. You are probably right in checking to make sure that bumping
> > up that limit of the hostname length would not result in a buffer
> > overflow somewhere downstream.
> > You should probably check that inet_addr() and all other relevant 
> > functions define the variables of the type and length that can
> > handle this longer input.
> > 
> > I noticed that some Linux (2.6.26-2-686) I had access to, was
> > capable of handling that long host name. So, you might want to pick
> > at how it is handled by Linux. (Unless that might create some sort
> > of copyright/license issues.)
> 
> Looking over the fence, the Linux traceroute calls getaddr(), which
> does check against hostname length and also has a limit of 64.
> Calling traceroute with anything longer than 64 chars will result in a
> "traceroute: hostname "abcdefghi.abcdefghi.abcdefghi.ab..." is too
> long" error.
> 
> Solaris, on the other hand, calls a getaddr() in getaddrinfo
> (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsocket/inet/getaddrinfo.c),
> which checks against a MAXHOSTNAMELENGTH=256 defined in netdb.h
> (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv/netdb.h).
> Anyway, it performs for the example from the PR. When supplying an
> arbitary string longer than 255 chars, traceroute from Solaris
> terminates with a memory allocation error as defined in EAI_MEMORY
> (also defined in netdb.h). 
> 
> TrustedBSD has the same <64 chars limit and is, I gather, not too
> dissimilar.
> 
> As an aside, inet_addr() is, i gather, part of POSIX
> (http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_addr.html),
> so I wonder, why so many do not implement inet_getaddr(), but have
> some home-brew called get_addr()?

Sorry, I got confused. Using inet_addr() to lookup a hostname is
complete rubbish, it's getaddrinfo(). And of course
getaddrinfo() is part of POSIX
(http://pubs.opengroup.org/onlinepubs/009695399/functions/getaddrinfo.html). 

Hope I'll not get too confused to make any sense ... 
-- 
Christopher J. Ruwe
TZ GMT + 2