>>>> IP_RECVIF gets you the if_index value for the interface [...]
>>> [...wishing for something "more useful" than that...]
>> What would you consider "useful"?  The if_index values are the only
>> unambiguous fixed-size names interfaces have, as far as I know.
> if i receive a datagram on a socket, i (naively?) expect that the
> interface will still be there by the time i construct a reply that i
> wish to send out said interface,

This will _probably_ be true, and if it isn't, it's probably no big
deal as long as the failure mode is not too catastrophic.

> in which case the interface "name" and "address" (which have the same
> lifetime issues as the number)

I don't think so, not if numbers are assigned sequentually at boot and
never repeated.  In practice today, a 32-bit serial number will never
be repeated; a 64-bit probably will never be repeated for the
foreseeable lifetime of NetBSD.  Interface name strings and addresses
tend to repeat, and generally are not fixed-size anyway (though I'm not
sure how much difference that last makes for IP_RECVIF).  I don't know
offhand whether if_index numbers satisfy this criterion.

> are much more useful since i don't have to do dig in the kernel for
> them.  dig here equates to something like SIOCGIFCONF.

But how could you use either one?  What you really want is your
application's internal name for an interface, and what's most useful
for locating that depends on why you care about which interface is
which.

>>> i tried adding an arp entry via a routing socket once.  [...]
>> [Routing messages] _are_ poorly documented.  [...]
> not very well documented *or* implemented.  imho, me getting it wrong
> as part of my learning process should not incur punishment in the
> form of the kernel panicking.

I'm inclined to agree with you in this case.  But when you're running
as root, the "userland being able to panic the machine is always a bug"
dictum is no longer really valid; consider dd if=/dev/zero of=/dev/mem.
I've tried a few times to draw a line on the far side of which is stuff
like that dd, for which it's unreasonable to expect that dictum to
hold, and on the near side of which is stuff like ls, for which it's
not.  So far I've not come up with anything even vaguely satisfactory.

> hmm...i guess i oughta fix that a little.  :)

:-)

/~\ 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