On Wednesday, 16 July 2025 15:05:17 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> 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 actually can't find that in the C++ standard. It is in the C one, though:

"6.2.6.2 Integer types

For unsigned integer types other than unsigned char, the bits of the object
representation shall be divided into two groups: value bits and padding bits
(there need not be any of the latter)."

> 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.

In C++, that's just std::numeric_limits<T>::digits.

> 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)

Indeed.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering