>  | they're done incredibly wrong then.  my understanding of the
>  | "canonical" way to use SIOCGIFCONF was to call it once with an empty
>  | struct ifconf (ie, ifc_buf is null and ifc_len is zero), and then
>  | malloc a buffer of the size returned in ifc_len.  probably with a pad
>  | so that any *new* addresses that show up in between your first a
>  | second calls are also covered.  it's simple to check that you didn't
>  | "get back" more data than you expected if you save the value of
>  | ifc_len between the first and second calls.
>
>This might be the case, but no code I found in the NetBSD tree from a
>quick glance revealed that non used the "canonical" way you describe
>(and is described on p435 of Stevens' Unix Network Programming 2nd ed.
>Vol I [UNP2VI]).

really?  neat!  i jsut thought that was the best way to do it.

>  | >IIRC, SIOCGIFCONF also can't support sockaddr_in6 addresses, or any
>  | >other sockaddr > 16 bytes long...
>  | 
>  | from a program i wrote a while back for a reason i don't remember...
>  | 
>  | 	% ./printifaddrs 
>  | 	ep0: fam=INET6 len=28 addr=fe80:8::210:4bff:fe9f:ab87
>  | 		(port=0 flow=0 scope=0)
>
>Is the program just using the struct ifreq returned from SIOCGIFCONF?
>There doesn't appear to be room in struct ifreq for a sockaddr_in6,
>and this is confirmed in on p 437 of UNP2VI.

it uses a struct ifconf, a pointer to which is the argument to
SIOCGIFCONF, not a struct ifreq.  then i simply march a struct ifreq
pointer through the buffer filled in by the kernel.  ignoring the fact
that a struct ifreq is too small seems not to be an issue, if you obey
the size indicated by the sa_len in each sockaddr.

i'll mail you the program under a separate cover.  no need to spam the
list with it.  :)

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."