Re: [Tinycc-devel] Bug Report (offset+cast)

[Dave Dodge]

On Fri, May 11, 2007 at 09:36:20PM -0400, Rob Landley wrote:
> On Friday 11 May 2007 3:01 pm, Dave Dodge wrote:
> > Aside: from a purely C standpoint the memcpy() solution isn't actually
> > guaranteed to work either, thanks to C99's concept of padding bits.
> 
> What are "padding bits"?

For integer types other than unsigned char, C99 allows the
representation to contain padding bits which do not contribute to the
integer's value.  Accessing an integer via a byte array gives you
access to the entire representation, including the padding bits.
Storing arbitrary data into padding bits (as with memcpy()) can lead
to undefined behavior.

An example in the Standard (in a footnote) is the case of an integer
representation having a padding bit for a hardware parity check.  If
you fill the entire representation with random bits, you might end up
with the parity bit flipped the wrong way, leading to a trap when you
tried to use it as an integer.

There are other unexpected things that can be true thanks to padding
bits, such as sizeof(short) being larger than sizeof(int) even while
range of short is smaller than the range of int.

> I strongly suspect this isn't something Linux has to worry about...

Right, I don't know of any hardware Linux runs on that uses padding
bits.  POSIX also constrains the implementation more tightly than
plain C -- for example requiring that bytes be exactly 8 bits --
though I'm not sure it forbids padding bits in the basic types.

There presumably are real devices that use padding bits, but they're
probably special-purpose targets rather than CPUs.  The C Standard has
a lot of strange little corner cases in it that you almost never
encounter in real life.  I've heard the DSP world has some unusual
ABIs with 32 or 64-bit bytes, and Cray had a CPU where 8-bit
addressability was simulated in the runtime by using extra bits in the
MSB of a pointer.

                                                  -Dave Dodge