Generalizing Integers (was Re: Specifying int size in C)

[Mark A Terribile]

> >> >	int:32	x, y;
> >> >	int:36	z;	/* Unisys 1100 compatibility :-> */
> >> >	int	a:8, b:9, c:6;

> >... the semantics are not quite as good as int:n would be.
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> Agreed.  I realize that this is a C-related posting, but has anyone 
> yet pointed out that PL/I had relevant features a quarter-century ago ?
 
>     dcl (x, y) fixed bin(31),
>         z      fixed bin(35),  /* Unisys/UNIVAC 1100 fullword */
>         a      fixed bin(7),
>         b      fixed bin(8),
>         c      fixed bin(5);

See the example on pp 23-25 of Kernighan and Plaugher, *The Elements of
Programming Style*, second edition.

The problem with the PL/I approach is that the programmer is encouraged to
think of such declarations as ``normal.''  The results are strange conversions
leading to hard-to-find, hard-to-predict bugs which occur on boundaries that
cannot be easily guessed at in either inspection, walk-through, or white-box
testing, and leading also to extra code size and execution costs.

Bringing the complexity of code, seen as a cultural phenomanon, under some
kind of control required going to a simpler model of computation, required
going from PL/I to B.  As the limits of the simpler model(s) were discovered,
they were expanded incrementally, first by going to C and then by extending
C bit by bit.

The present ``mental model'' conjured up by bitfields is a model of an
exceptional or special case which is used when certain tradeoffs can be
accepted, and not otherwise.  For the moment, it does seem to be the best
way to view the bitfield.

PL/I did a lot of things.  It did a surprising number of them right.  It did
even more almost right.  That wasn't good enough, though.
-- 

(This man's opinions are his own.)
>From mole-end				Mark Terribile