>>> [...], however, a number of people have pointed out to me that it
>>> 3rd-party programs may rely on sockaddr_dl's size remaining the
>>> same.
>> Could you explain this in more detail?  [...]
> A third-party program might abuse sockaddr_dl by embedding it into a
> wire format and assuming a fixed length.

Sure.  But a third-party program might also assume little-endian; does
this mean that we have to avoid big-endian hardware?  No, it means such
software is broken - at least if it's intended to be general-purpose.

Similarly, software that blindly assumes that a sockaddr_dl happens to
match a wire format, even if that format was defined based on what a
sockaddr_dl happened to look like at some point, is similarly broken.

Except for a very few structs defined that way for the purpose, it is
simply _broken_ to assume that a struct looks like anything in
particular when viewed as a chunk of bytes (as when overlaying it onto
a wire octet stream).  (The only examples I can think of offhand for
the "very few" are things - like struct ip - that are not really
intended for general-purpose application code.)

> If you recompile the program on NetBSD, then it might not be able to
> speak with a second instance of the program, if that instance was
> compiled with a different/older net/if_dl.h.

Right.  This means the application code needs fixing.

I can write code that won't be able to interoperate between sparc and
vax because they use different floating-point formats.  Does this mean
we need to have one of them fake the other's floating-point format?  No,
it means the application code is broken in that portability respect!  I
believe that the brokenness you describe is a bug in the application,
and explosing it this way is doing its author(s) a favour by pointing
up their erroneous assumptions.

I once ran into a wire protocol that depended on the exact layout of
the internal key schedules used by a particular DES library.  Does this
mean that another DES library has to use the same key schedules?  No,
it means there's a portability bug in the protocol design!

> A hypothetical 3rd-party program that reads/writes AF_LINK sockaddrs
> from/to the kernel, today, and that assumes AF_LINK sockaddrs of
> fixed length, has always been broken.  It will remain broken.
> However, a hypothetical 3rd-party program that sends/receives AF_LINK
> sockaddrs of fixed length to/from instances of itself will not break,
> because we will not change the length of sockaddr_dl.

Such code has always been broken and will remain broken; I don't see
why it's a good thing to conceal this brokenness.  There's no guarantee
our sockaddr_dl matches anyone else's; indeed, if sdl_index values not
multiples of 257 are used, our sockaddr_dl is not compatible between
arches of different endianness right now.  As long ago as 1.4T,
sdl_data was already commented as "can be larger; contains both if name
and ll address".  We cannot protect idiot code authors from all the
ways they can be idiots, and I believe it is no favour to them to try.

Do you know of any non-hypothetical examples?  I suspect that such code
is rare enough that, quite aside from the principles I outlined above,
it's not unreasonable to not care about it.

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