As per C99, there maybe padding bits in signed int
or unsigned int
representation . So I wonder are there still any implementations having such outdated things?
Quoting the C99 rationale (PDF) section 6.2.6.2 §20:
Padding bits are user-accessible in an unsigned integer type. For example, suppose a machine uses a pair of 16-bit shorts (each with its own sign bit) to make up a 32-bit
int
and the sign bit of the lowershort
is ignored when used in this 32-bitint
. Then, as a 32-bitsigned int
, there is a padding bit (in the middle of the 32 bits) that is ignored in determining the value 20 of the 32-bitsigned int
. But, if this 32-bit item is treated as a 32-bitunsigned int
, then that padding bit is visible to the user’s program. The C committee was told that there is a machine that works this way, and that is one reason that padding bits were added to C99.
So such things at least did exist.
As for weird architectures still around today, the go-to example is the UNIVAC 1100/2200 series with its weird data formats.
While it does not use integer padding, a look at their C compiler manual (PDF) is still instructive:
Table 4–4. Size and Range of Unsigned Integer Types
Type Size Range
unsigned short int 18 bits 0 to (2^18)–1
unsigned short
unsigned int 36 bits 0 to (2^36)–2 (see the following note)
unsigned
unsigned long int 36 bits 0 to (2^36)–2 (see the following note)
unsigned long
The second volume (PDF) explains how the CONFORMANCE/TWOSARITH
compiler keyword can be used to control interpretation of negative zero: this adjusts the range of the unsigned integer types to the expected (2^36)-1 but comes with a performance penalty on unsigned arithmetics.