Re: struct sockaddr_storage issues

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I think getaddrinfo() has a lot of baggage.

It has some.  But so does every other option.  You just have to pick
which set of baggage you prefer.

For all of my purposes, I find getaddrinfo() to be the best of the
available options.  I would not reject it for other purposes without a
very compelling reason.

Perhaps you have one, even if only "what I'm used to".  It's your code;
it's your choice.

>> I've seen reports of buggy getaddrinfo() implementations on some
>> platforms,

And other options don't have bugs anywhere?

> As far as I can tell, if you used getaddrinfo() it would result in
> less code and zero portability concerns

I wouldn't go that far.  getaddrinfo() has its own issues, perhaps most
notably the definition of the hints argument, which requires either
writing nonportable C or ignoring future-proofing.  (You have to either
clear the unused fields by assignment, which ignores future-proofing in
that it hardwires the set of fields being cleared, or you have to use
bzero or moral equivalent, which ignores the nonportability of assuming
all-0-bits is a nil pointer.)

Still, though, as I remarked above, I consider it the least problematic
of the available options for most purposes.  I don't understand why
they (FWVO "they") haven't fixed the API; it wouldn't even be hard.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B