Re: [TUHS] v7 K&R C

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

There was a recent message I now can't find that I wanted to reply to,
something about which type to use to get a certain effect.

I wanted to reply to say that I felt that it was not really the best way to
go, to have one set of type names that tried to denote both i) the semantics
of the data, and ii) the size of the item, using arbitrary names.

This came up for me when we started to try and write portable networking code.
There, you need to be able to specify very precisely how long fields are
(well, in lower-level protocols, which use non-printable formats). How to do
that in a way that was portable, in the compilers of the day, was a real
struggle. (It might be doable now, but I think the fixes that allowed it were
still just patches to something that had gone in the wrong direction, above.)

I created a series of macros for type definitions, ones that separately and
explicitly specified the semantics and size. They looked like 'xxxy', where
'xxx' was the semantics (signed and unsigned integers, bit field, etc),
and 'y' was a length indication (byte, short, long, and others). So you'd
see things like 'unsb' and 'intl'.

The interesting twist was a couple of unusual length specifiers; among them,
'w' stood for 'the machine's natural word length', and 'f' meant 'no
particular length, just whatever's fastest on this architecture/compiler, and
at least 16 bits'. The former was useful in OSy type code; the latter for
locals and things where nobody outside the machine would see them.

Then you'd have to have a file of macro definitions (only one per machine)
which translated them all into the local architecture/compiler - some didn't
go, of course (no 'unsb' on a PDP-11), but it all worked really, really well,
for many years.

E.g. at one point, as a dare/hack, I said I'd move the MOS operating system, a
version written in portable C (with that type name system) to the AMD 29000
over one night. This wasn't totaly crazy; I'd already gotten the debugger (a
DDT written in similar portable C) to run on the machine, so I knew where the
potholes were. I'd have to write a small amount of machine language (which I
could traslate from the M68K version), but most of it should just compile and
go. I didn't quite make it, it wasn't quite running when people started coming
in the next morning; but IIRC it started to work later that day.

   Noel