BSD didn't even save a size_t by doing this

Posted Nov 7, 2024 19:37 UTC (Thu) by NYKevin (subscriber, #129325)
Parent article: The trouble with struct sockaddr's fake flexible array

As I read this, it looks like this comes down to a poor design decision in the initial API, namely the choice to use a statically-sized array instead of a dynamic array. It's easy to claim that this would have made sense at the time because it saves a size_t... but that's not actually true:

> The sa_family field describes which address family is in use — AF_INET for an IPv4 address, for example. sa_data holds the actual address, the format of which will vary depending on the family. The implementation notes say that: "the size of the data field, 14 bytes, was selected based on a study of current address formats". In other words, 14 bytes — much longer than the four needed for an IPv4 address — should really be enough for anybody.

A size_t (or the moral equivalent in pre-standards C) has never been 10+ bytes on any real platform that people have used for serious purposes, with the possible exception of a small handful of natively 128-bit supercomputers. If you're willing to waste 10 bytes in the extremely common case of IPv4, you should be willing to spend 4 bytes on a size_t/long/whatnot (or however many bytes a size_t-ish was in 1983), since that would net out to 6 bytes saved in the case of IPv4. I think the more plausible explanation is that somebody didn't feel like writing the extra code to initialize the size field.

(And no, using something other than a size_t due to its lack of standardization would not have caused problems today. Unless there's some weird networking protocol I don't know about that requires addresses bigger than 64K, a 16-bit size field would still be more than adequate even if it would be a bit nonstandard.)

BSD didn't even save a size_t by doing this

Posted Nov 7, 2024 20:53 UTC (Thu) by khim (subscriber, #9252) [Link]

> I think the more plausible explanation is that somebody didn't feel like writing the extra code to initialize the size field.

The simple explanation is that was 1983. Time where backward compatibility started becoming important but no one really felt it would become critical.

Just five years before that FORTRAN removed some pieces from standard without anyone batting an eye!

Surely it's a software, it's malleable, people would just fix it later, when requirements would change?

It's only when people started dragging feet with upgrade to FORTRAN 77, when people essentially boycotted MS-DOS 4.0 (in 1988!) because it changed some internal data structures which “programs were not supposed to ever touch”, only when OS/2 completely imploded because someone decided to “improve” Presentation Manager API… only then developers of operation systems realized that keeping ABI stable would make or break them (and even after that moment Linux developers denied the obvious for decades, but that's another thing).

I would bet that no one expected to see sockaddr, casually introduced in 1983 just for the “large-scale experiment” (as Vint Cerf attests IPv4 was envisioned as large-scale experiment, no one expected it to be used outside of academy and there were expectation that another thing or yet another thing would be used by everyone else) – would still be in use 40 years later and would affect hundreds of billions devices… if they have heard about it they would have assumed you have lost all your marbles.