>> getaddrinfo()'s interface contract makes no promises about what
>> order the returned list is in.
> Yes, I figured as much.  Seems like the (or at least _a_) more
> correct thing to do is to loop over all the AI_PASSIVE addresses
> returned and open a listening socket for each.

That phrasing indicates a belief that the ai_flags field of the
returned structures is useful.  This is not so.  The NetBSD manpage
does not mention it, but RFC3493 explicitly says "The contents of the
ai_flags field of the returned structures are undefined.", which,
grammar mistake aside, seems to me pretty clear.

> Would an fd_set be appropriate for carrying around the group of
> listening fds opened, since we don't actually know how many sockets
> we'll open?

In my opinion it would be a suboptimal approach.  There are at least
two problems with it: (1) there is no particularly easy way to loop
over all fds in an fd_set, short of looping from zero to some max and
checking each one; and (2) if you ever happen to get a fd above
FD_SETSIZE, your code will break.  (I recently had to find breakage in
some code that blindly assumed any fd would fit in an on-stack fd_set;
when the fds got too high, it started trashing its stack.)

> Right now, the code passes around a single "listen_fd", so I'd like
> to suggest some changes that have the least impact on the code
> structure, and changing it to pass around an fd_set seems (to my
> untrained eye, anyway) to be the simplest change to make.

Probably, but the price it carries for the code is..unpleaseant, at
least, to me.  (Personally, I usually use a linked list of small
structs.)

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