Andrew McGregor wrote: Hi,
On 25/08/2009, at 10:24 AM, Ahrenholz, Jeffrey M wrote:Based on this discussion, it appears that the best way for future proofing is to include a flag for getaddrinfo() in the hints arguments that will result in sockaddr_hip_long structures instead of sockaddr_hip. This way, applications get exactly what they want and can store the HITs easily in their ACLs. I'd also remove the extra space reserved space because it seems that it's not very usable for future proofing as it is now. Jeff, how do you feel about this or do you have a better suggestion?I think you'd be better to define more than a flag... an explicit size (or enum) would be better. That way if some other odd size becomes a requirement later, it's not such an annoyance to fit in to the APIyes, a size or flag makes sense; looks like struct addrinfo already has "size_t ai_addrlen;" but that field must be zero when used as hints (looking at getaddrinfo(3) man) other calls such as connect(), bind(), and sendto() already take a "socklen_t addrlen" argument
the socket address structure already contains the size of the socket within the first field. Having yet another size within the structure or a variable length socket address structure is confusing for people used to constant size structures such as sockaddr_in, sockaddr_in6 and sockaddr_storage.
Have a look at section "EXAMPLES" on getaddrinfo() FreeBSD man pages: http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=getaddrinfoIf there is an additional length field and it must be used in socket calls, it disrupts the flow of the client side example.
Ah, in that case... getaddrinfo should return whatever it can, and applications should be required to check lengths if they care. That avoids coding in bugs early.
The problem is that they do have check lengths when the applications fill in the socket address structures by themselves. I think it also a show stopper for allocations from the heap (struct addrinfo foo;). Dynamic allocations get somewhat tricky because defining the allocated size is not trivial.
A way to avoid the memory-related problem and "client flow" problem would be to define sockaddr_hip to contain the maximum number of bytes similarly as sockaddr_storage does. Would that work for you?
We would still need the actual HIT field to be defined as an union to facilitate naming of larger HITs withing the structure in a backwards compatible way. Right?