Mauro Tortonesi <[EMAIL PROTECTED]> writes: >> I still don't understand the choice to use sockaddr and >> sockaddr_storage in a application code. >> They result in needless casts and (to me) uncomprehensible code. > > well, using sockaddr_storage is the right way (TM) to write IPv6 enabled > code ;-)
Not when the only thing you need is storing the result of a DNS lookup. I've seen the RFC, but I don't agree with it in the case of Wget. In fact, even the RFC states that the data structure is merely a help for writing portable code across "multiple address families and platforms". Wget doesn't aim for AF independence, and the alternatives are at least as good for platform independence. >> For example, this cast: (unsigned char *)(&addr->addr_v4.s_addr) >> would not be necessary if the address were defined as unsigned >> char[4]. > > in_addr is the correct structure to store ipv4 addresses. using > in_addr instead of unsigned char[4] makes much easier to copy or > compare ipv4 addresses. moreover, you don't have to care about the > integer size in 64-bits architectures. An IPv4 address is nothing more than a 32-bit quantity. I don't see anything "incorrect" about using unsigned char[4] for that, and that works perfectly fine on 64-bit architectures. Besides, you seem to be willing to cache the string representation of an IP address. Why is it acceptable to work with a char *, but unacceptable to work with unsigned char[4]? I simply don't see that in_addr is helping anything in host.c's code base. >> I don't understand the new PASSIVE flag to lookup_host. > > well, that's a problem. to get a socket address suitable for > bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. Why? The current code seems to get by without it. There must be a way to get at the socket address without calling getaddrinfo. > are there __REALLY__ systems which do not support inet_aton? their > ISVs should be ashamed of themselves... Those systems are very old, possibly predating the very invention of inet_aton. >> If it would make your life easier to add TYPE in !ENABLE_IPV6 case, >> so you can write it more compactly, by all means do it. By "more >> compactly" I mean something code like this: >> [...] > that's a question i was going to ask you. i supposed you were > against adding the type member to ip_address in the IPv4-only case, Maintainability is more important than saving a few bytes per cached IP address, especially since I don't expect the number of cache entries to ever be large enough to make a difference. (If someone downloads from so many addresses that the hash table sizes become a problem, the TYPE member will be the least of his problems.) > P.S. please notice that by caching the string representation of IP > addresses instead of their network representation, the code > could become much more elegant and simple. You said that before, but I don't quite understand why that's the case. It's certainly not the case for IPv4.
