How to find the alignment requirements of a give type in the C99 standard?

[xmllmx]

6.2.5.6 says:

"For each of the signed integer types, there is a corresponding (but
different) unsigned integer type (designated with the keyword
unsigned) that uses the same amount of storage (including sign
information) and has the same alignment requirements."

However, I can't find any definition of the alignment requirements of
a given type via full-text search.

Below is my understanding:

To begin with code:

long long m = 0x12345678ABABCDCDLL;
long long* p = &m;
bool b = ((int)p) % 8);

To comply with the C99 standard, the compiler must ensure b is always
false. Is this correct? If this is correct, then where to find such
rules in the standard?

 

[Gordon Burditt]

6.2.5.6 says:

"For each of the signed integer types, there is a corresponding (but
different) unsigned integer type (designated with the keyword
unsigned) that uses the same amount of storage (including sign
information) and has the same alignment requirements."

However, I can't find any definition of the alignment requirements of
a given type via full-text search.

They are implementation-defined.

Below is my understanding:

To begin with code:

long long m = 0x12345678ABABCDCDLL;
long long* p = &m;
bool b = ((int)p) % 8);

((int)p) % 8 isn't guaranteed to compute anything useful. It might
extract the lower 3 bits of the memory segment number, which may
be a constant for all addresses in a small memory model. In
particular, it is *NOT* guaranteed to give any indication of whether
the long long m is aligned to a multiple of 8.

There is no guarantee that sizeof(long long) = 8, nor that the alignment
of a long long has anything to do with the number 8.

To comply with the C99 standard, the compiler must ensure b is always
false. Is this correct?

No. It is possible that a long long is allowed to be byte-aligned.

 

[xmllmx]

Thanks. I'm clear now.

 

[Richard Bos]

They are implementation-defined.

There is no guarantee that sizeof(long long) = 8, nor that the alignment
of a long long has anything to do with the number 8.

However, there is a guarantee that the alignment of any type has
something to do with sizeof(that type). It is not possible for the
alignment requirements of <type> to be stricter (i.e., for <type> to be
required to be aligned on a larger amount of bytes) than sizeof(<type>),
because in a <type> array[], array[1] must have the address of array[0]
plus exactly sizeof(<type>) bytes.
It _is_ allowed for <type>'s alignment to be less restrictive than
sizeof(<type>), as Gordon already implied, and it's even allowed
(although I've never seen any such system, and would be highly surprised
if it existed) for <type> to need to be aligned to an address which, if
converted to a intptr_t, to be equal to N*sizeof(<type>)+(a constant <
sizeof(<type>) but >0).

That, I think, is all that's required. It isn't much.

Richard

 

[Gordon Burditt]

6.2.5.6 says:

They are implementation-defined.

There is no guarantee that sizeof(long long) = 8, nor that the alignment
of a long long has anything to do with the number 8.

However, there is a guarantee that the alignment of any type has
something to do with sizeof(that type). It is not possible for the
alignment requirements of <type> to be stricter (i.e., for <type> to be
required to be aligned on a larger amount of bytes) than sizeof(<type>),
because in a <type> array[], array[1] must have the address of array[0]
plus exactly sizeof(<type>) bytes.

It _is_ allowed for <type>'s alignment to be less restrictive than
sizeof(<type>), as Gordon already implied,
OK

and it's even allowed
(although I've never seen any such system, and would be highly surprised
if it existed) for <type> to need to be aligned to an address which, if
converted to a intptr_t, to be equal to N*sizeof(<type>)+(a constant <
sizeof(<type>) but >0).

I have reservations about this one. I won't argue that you can't
require odd alignment or some such thing. The implementor has to
be careful that since malloc() must return a pointer for suitable
alignment of all objects, one object type requiring alignment on
an odd address means all the others must allow alignment on an odd
address. So: no "integers with size > 1 and floating point on
even address boundaries, pointers on odd boundaries".

But who says that when you convert an address to an intptr_t, the
low-order bits of the address end up in the low-order bits of the
intptr_t? You can talk about alignment to a physical address, but
what if the alignment of the physical address is not something you
can figure out without implementation-specific knowledge?

Example: a pointer consists of the following parts:

- a memory segment number (for virtual memory mapping)
- a CPU ring number
- a local / global bit to select which mapping table to use
- a page offset
- an offset within a page.

(Pentium 48-bit protected-mode pointers look somewhat like this).

The first four designate a "page" (some chunk of memory large
compared to C basic types, say, 4096 bytes), and the last is used
to select a specific address within the page. Now, suppose that
the pointer format puts the bits in the native pointer format order
(as is the intptr_t) and the "offset within the page" is *NOT* at
either end of the pointer (or the intptr_t). You *CANNOT* determine
the alignment of a particular pointer without knowing the
(hardware-specific) location of the low-order bits of the address
within the pointer. (Oh, yes, the compiler has to use special
"increment address" vs. "increment integer" code. And code like:

char *p = (some value here);

p+1
is unlikely to be the same as
(char *)(((intptr_t)p)+1)

As another example: consider the 8086 segmentffset 32-bit format,
only swap the ordering of the two 16-bit parts. The low-order bits
of an intptr_t have nothing to do with alignment.