Noel Chiappa wrote:
From: Larry
McVoy
Not once did I think about packing, the structs
somehow just worked on
the machines I was working on. Maybe the TCP/IP guys knew about spacing
in the structs.
Not really! Of the first 6 TCP/IP implementations:
only 1 was in C - and it was a relatively late one. The earliest ones were
mostly in assembler (PDP-10 and PDP-11).
BUT, the basic TCP and IP protocols seem to have been created with a
general care that two byte fields should be aligned at multiples of
two bytes and four byte fields should be at multiples of four bytes,
or at the VERY least, no multi-byte field should cross a four byte
boundary (which would have been a pain to PDP-10 programmers who
likely expected 32 bits of data in each 36 bit word).
IP and TCP Options may blow that out of the water, I don't recall.
ISTR that in the IL protocol (atop IP) in early Plan9, the four byte
sequence numbers would cross over the lines in a traditional RFC box
diagram.
And for early TCP/IP networking and alignment pain (with Unibus!):
I briefly looked at gluing the TCP/IP stack in MIT-ITS for the 2020
(KS10, a PDP-10) which had a Unibus, to the driver someone had written
a Unibus Interlan NI1010 card, BUT the 14 byte Ethernet header meant
the 32-bit words in the TCP and IP headers landed across the (36 bit)
word boundaries expected by ITS' TCP stack (that had been written to
speak to IMPs). There might have been an (MIT added?) BLT to move
8-bit bytes around (or the DEC EXTEND MOVSLJ might have been
available), but it was too gross to contemplate... I suppose Berkeley
trailers might have solved the problem (had I known about them at the
time, but.... also gross).
And as for C: It was born on a 16-bit word system that expected 16-bit
aligned words, replacing B, a language with just the word datatype, on
a system with a 32KB (or less) user space, by people who had just come
from a project where waiting for working production PL/I compiler had
been a major headache, and generally suffered from "second system
syndrome" bloat.
I think it's fair to say that the essence of UNIX and the brilliance
of the development team (largely lost on modern developers) was to
make it as simple as possible, but no simpler.
IMO judging Unix, C and it's creators by criteria like "how could they
not have anticipated my alignment problems" (or why isn't C like PL/I)
is armchair quarterbacking. If you feel otherwise, maybe you should
travel back in time and join the Unix-Haters mailing list, or at least
not be on this one, insulting people who were involved, and are kind
enough to put up with our inane blathering...