Re: [Hipsec] draft-ietf-hip-native-api-09-pre

[Andrew McGregor <[e-mail]>]

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 API
>
> yes, 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
>
> -Jeff
>

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.

Andrew