Question

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?

Answer 1

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 lower short is ignored when used in this 32-bit int. Then, as a 32-bit signed int, there is a padding bit (in the middle of the 32 bits) that is ignored in determining the value 20 of the 32-bit signed int. But, if this 32-bit item is treated as a 32-bit unsigned 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.