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

[Andrew McGregor <andrew at indranet.co.nz>]

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