On Wed, Jul 16, 2025 at 12:09 PM Jan Schultke wrote:
>
> I don't see how a separate octet type would help. It couldn't actually
> be narrower than a byte anyway; it could just have some padding bits.
> The strategy on non-8-bit-platforms is to just leave some bits unused
> for operations that use char/unsigned char, and that seems fine for
> networking too. You don't actually need an octet type.


You're allowed to have padding bits in every unsigned integer type
other than unsigned char. Unsigned char must have zero padding bits.

I remember 20 years ago, most people got the number of value bits in
an integer type by doing:

    CHAR_BIT * sizeof( unsigned_integer_type )

But really you had to do:

    CHAR_BIT * IMAX_BITS( (unsigned_integer_type) -1 )

just in case you're dealing with a 36-Bit int that has 4 padding bits.
But maybe those machines went out with the dinosaurs.

I always thought that the biggest thing about having a fluidic
CHAR_BIT was to accommodate supercomputers that only have 1 integer
type:

CHAR_BIT == 64
1 == sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) ==
sizeof(long long)