[Freeciv-Dev] Re: Hostname lookups again.

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>]

On 19 Sep 2000, Gaute B Strokkenes wrote:

> Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> writes:
> 
> > On 18 Sep 2000, Gaute B Strokkenes wrote:
> > 
> > > I have attached a (slighly) updated version.  It's a very
> > > straightforward fix.  It would be great if someone gave me some
> > > feedback, or just applied the damn thing...
> > 
> > Well, i really don't see why you're making all those checks to see if a
> > name is of the AF_INET family in look up using gethostbyname().  It's not
> > like DNS is used for non IP stuff...  as far as i know...
> 
> AF_INET6.  There are various other, though less common, possibilities
> as well.

Such as?  gethostbyname() calls the resolver which calls DNS.  If DNS is
used over anything else than IP let me know.

As for AF_INET6... well check this
(from http://community.roxen.com/developers/idocs/rfc/rfc2553.html):

"
6. Library Functions 

New library functions are needed to perform a variety of operations with
IPv6 addresses. Functions are needed to lookup IPv6 addresses in the
Domain Name System (DNS). Both forward lookup (nodename-to- address
translation) and reverse lookup (address-to-nodename translation) need to
be supported. Functions are also needed to convert IPv6 addresses between
their binary and textual form. 
We note that the two existing functions, gethostbyname() and
gethostbyaddr(), are left as-is. New functions are defined to handle both
IPv4 and IPv6 addresses. 


6.1 Nodename-to-Address Translation 


The commonly used function gethostbyname() is inadequate for many
applications, first because it provides no way for the caller to specify
anything about the types of addresses desired (IPv4 only, IPv6 only,
IPv4-mapped IPv6 are OK, etc.), and second because many implementations of
this function are not thread safe. RFC 2133 defined a function named
gethostbyname2() but this function was also inadequate, first because its
use required setting a global option (RES_USE_INET6) when IPv6 addresses
were required, and second because a flag argument is needed to provide the
caller with additional control over the types of addresses required. 
The following function is new and must be thread safe: 

#include <sys/socket.h> #include <netdb.h> 

   struct hostent *getipnodebyname(const char *name, int af, int flags
                                       int *error_num);
The name argument can be either a node name or a numeric address string
(i.e., a dotted-decimal IPv4 address or an IPv6 hex address). The af
argument specifies the address family, either AF_INET or AF_INET6.
"

So your check is redundant.  Case closed.

> I'm not that familiar with inetv6, and I don't have the opportunity to
> test it either, but I'd be surprised if Freeciv compiled and ran
> cleanly on such a system.  I'm just insuring that we'll fail cleanly
> rather than crash and/or play yankee doodle or anything else funny
> when the time comes.  When/if inetv6 becomes popular, it should be
> easy to adapt Freeciv anyway.
> 
> > And it's not like replacing the memcpy()'s with attributions is
> > doing much too.
> 
> My problem with that code was that it would use the size field in the
> result of the look-up to determine how much to copy.  I didn't
> investigate the affected data structures too much, but sooner or later
> you'll end up being sorry for copying a 128-bit inetv6 address instead
> of a 32-bit inetv4 address.  If you prefer memcpy() over struct
> assignments, please feel free to change it back.  But do it
> properly... >8-)

What's wrong about the memcpy()?  The only problem which you mention is is
gethostbyname() returns some address which is not of the AF_INET type i
know of no such case.  The RFC claims it only returns IPv4 addresses.  But
if you want that check, fine by me...  But give me *one* real case where
it isn't true before adding superfluous checks.

> Actually checking the length field of the look-up (when we've already
> ascertained that it's AF_INET) might be a bit anal, but why not.
> 
> > And we probably could use inet_aton() instead of inet_addr() since the
> > Linux man page says it's obsolete (funny hadn't noticed that before).
> 
> Or just forget about them altogether (as my patch does,) since
> gethostbyname() is supposed to do the right thing when presented with
> a dotted quad.  I suppose there might be brain-damaged systems out
> there that don't do this.  If anyone knows of one, they might wish to
> chime in.

Actually no.  I did this once in the past, and in Linux when libc couldn't
connect to DNS it failed to lookup the numbers and dots addresses (of
course noone uses Linux...).

You see, the lookup code not so long ago.  So it's not like that bit of
the code has been ignored.  Your point about the isdigit() is valid, but
everything else isn't.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa