Alignment, Cast

[anon.asdf]

Hello!

Is it legal to access a 4-byte int at any offset (alignment) in the
following array:

char arr[8] = {0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0, 1};
?? (See question 3 later...)
Example:

printf("%08x\n", *((int *) (arr + 0)));
printf("%08x\n", *((int *) (arr + 1)));
printf("%08x\n", *((int *) (arr + 2)));
printf("%08x\n", *((int *) (arr + 3)));

/*
Output assuming the following
~32 bit natural word size of processor
~little endian: the address of a single byte 'Q' corresponds with the
adress of a 4-byte int only, if that int has this same byte 'Q' as the
LSB

0d0c0b0a
0e0d0c0b
0f0e0d0c
000f0e0d
*/



4 Questions:
* assume 32-bit processor: natural word size is 4 bytes
* alignment: a 4-byte int is aligned if it lies on an address that is
a multiple of 4

1)
~Will "char arr[8]" always be 4-byte aligned (according to the natural
word size)???
~Or will it rather be 1-byte aligned (meaning it can lie where it
wants)???

(thinking ahead...) If not 4-byte aligned, but one desires a 4 byte
alignment, then one would have to use:
int arr_tmp[2];
char *arr = (char *)arr_tmp;

~would that work?
~any other possibilities?

2)
~Will "short sh;" (where short has 2 bytes) always be 4-byte aligned
(according to the natural word size)???

~If not, and one desires it to be 4-byte aligned, one could use:
int tmp;
#define sh ( *((short *)(&tmp)) )

~would that work?
~are there any other possibilities?

3)
*((int *) (arr + 1)) can be an unaligned 4-byte int-access (see
above). As can be seen above, it works with my gcc compiler. I believe
it splits into 2 accesses (that are then combined).
~Will it work on every standards-compliant C compiler (assuming int is
4 bytes)?
//That was a read.

//Now a write:
~ Is this legal:
int i;
*((int *)(arr+1)) = i;
? (It works with gcc!)
Does it depend on the C-compiler? Or on the processor? or...?

4)
(gcc...)

struct struc_a {
char a; /*1 byte */
short b; /*2 bytes*/
char c; /*3 bytes*/
} __attribute__ ((packed));

/*gcc extension*/

/* sizeof(struct struc_a) is 4. */

~Will "struct struc_a tmp" be 4-byte aligned?
~gcc: Could one align "struct struct_a tmp" so that it lies at an
addess x,
where x % 4 = 1 ?


---- Offtopic: ----
Are there any good books that can be recommended on C programming and
in particular how this relates to the actual machine code generated?

Things like:
alignment, byte-ordering, portable C programming, how loops are
implemented in machine code, optimization

I wonder if reading the C standard is beneficial (or in what respect
it would be beneficial)?
I'm really impressed by some people, who quote relevant information
directly from the standard!

Or reading a book on GCC?
Or maby Jens Schweikhardt's book, if it's ever finished:
http://www.schweikhardt.net/#mybook
Or Knuth's output?
?

At this point I think that practical programming combined with
comp.lang.c is the best resource, thanks to some really intelligent
people giving quality comments.
?
But still: I'm pretty sure going to have a *real* look at assembly
language and some debugger tools in the near future.

Thanks -Albert

 

[Eric Sosman]

Hello!

Is it legal to access a 4-byte int at any offset (alignment) in the
following array:

char arr[8] = {0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0, 1};

A four-byte type has an alignment requirement of 4,
2, or 1 bytes (the platform decides, and doesn't tell
you). Therefore, at least one of the offsets in the
array will be properly aligned for an int, if int is
four bytes wide.

4 Questions:
* assume 32-bit processor: natural word size is 4 bytes
* alignment: a 4-byte int is aligned if it lies on an address that is
a multiple of 4

1)
~Will "char arr[8]" always be 4-byte aligned (according to the natural
word size)???
~Or will it rather be 1-byte aligned (meaning it can lie where it
wants)???

The latter. Since `char' needs only 1-byte alignment,
the compiler does not need to align it more strictly.

(thinking ahead...) If not 4-byte aligned, but one desires a 4 byte
alignment, then one would have to use:
int arr_tmp[2];
char *arr = (char *)arr_tmp;

~would that work?

It would align the "`char' array" strictly enough for
an int. Under your assumption this means 4-byte alignment,
but that may not be true of all C implementations, or even
of all C implementatins where sizeof(int)==4.

~any other possibilities?

You can use a union to place objects of several types
at the same address, aligned well enough for the strictest
among them -- but it's not guaranteed that this will achieve
4-byte alignment.

You can acquire memory from malloc() et al., and this
will be aligned strictly enough for the most restrictive of
all C types (whatever that is). Again, this is not guaranteed
to have 4-byte alignment.

2)
~Will "short sh;" (where short has 2 bytes) always be 4-byte aligned
(according to the natural word size)???

A two-byte type requires either 2-byte or 1-byte
alignment. The compiler is not required to align it more
restrictively than the type needs.

~If not, and one desires it to be 4-byte aligned, one could use:
int tmp;
#define sh ( *((short *)(&tmp)) )

~would that work?
~are there any other possibilities?

See above. It's easy to get a group of objects aligned
so as to satisfy the strictest among them, but I can think
of no portable way to ensure 4-byte alignment.

3)
*((int *) (arr + 1)) can be an unaligned 4-byte int-access (see
above). As can be seen above, it works with my gcc compiler. I believe
it splits into 2 accesses (that are then combined).
~Will it work on every standards-compliant C compiler (assuming int is
4 bytes)?

No.

Does it depend on the C-compiler? Or on the processor? or...?

Yes.

4)
(gcc...)

struct struc_a {
char a; /*1 byte */
short b; /*2 bytes*/
char c; /*3 bytes*/
} __attribute__ ((packed));

/*gcc extension*/

/* sizeof(struct struc_a) is 4. */

~Will "struct struc_a tmp" be 4-byte aligned?

Ask in a gcc group.

~gcc: Could one align "struct struct_a tmp" so that it lies at an
addess x,
where x % 4 = 1 ?

Ask in a gcc group.

 

[Ben Bacarisse]

Hello!

Is it legal to access a 4-byte int at any offset (alignment) in the
following array:

No. In effect, all your other questions dissolve, but I'll go through
them...

4 Questions:
* assume 32-bit processor: natural word size is 4 bytes
* alignment: a 4-byte int is aligned if it lies on an address that is
a multiple of 4

1)
~Will "char arr[8]" always be 4-byte aligned (according to the natural
word size)???

You can't rely on that.

~Or will it rather be 1-byte aligned (meaning it can lie where it
wants)???

It may be. It may also be aligned in some other way.

(thinking ahead...) If not 4-byte aligned, but one desires a 4 byte
alignment, then one would have to use:
int arr_tmp[2];
char *arr = (char *)arr_tmp;

~would that work?
~any other possibilities?

See the recent thread. What are you really trying to do? There may
be a simple answer for you problem.

2)

As above.

3)
*((int *) (arr + 1)) can be an unaligned 4-byte int-access (see
above). As can be seen above, it works with my gcc compiler. I believe
it splits into 2 accesses (that are then combined).
~Will it work on every standards-compliant C compiler (assuming int is
4 bytes)?

No. Use memcpy (or memmove if overlap is possible):

int i;
memcpy(&i, arr + 1, sizeof i);

//That was a read.

//Now a write:
~ Is this legal:
int i;
*((int *)(arr+1)) = i;
? (It works with gcc!)
Does it depend on the C-compiler? Or on the processor? or...?

Ditto: memcpy(arr + 1, &i, sizeof i);

4)
(gcc...)

struct struc_a {
char a; /*1 byte */
short b; /*2 bytes*/
char c; /*3 bytes*/
} __attribute__ ((packed));

/*gcc extension*/

/* sizeof(struct struc_a) is 4. */

~Will "struct struc_a tmp" be 4-byte aligned?
~gcc: Could one align "struct struct_a tmp" so that it lies at an
addess x,
where x % 4 = 1 ?

Gcc has was for control alignment. They are off topic here. A gcc
groups will be able to tell you more than you want to know about this!

---- Offtopic: ----
Are there any good books that can be recommended on C programming and
in particular how this relates to the actual machine code generated?

Some would say that such a book would be, by definition, not good. I
would probably not go quite that far, but C has been plagued by its
appeal to those that prefer to fiddle than to write portable code.

<snip>

 

[Ben Bacarisse]

(thinking ahead...) If not 4-byte aligned, but one desires a 4 byte
alignment, then one would have to use:
int arr_tmp[2];
char *arr = (char *)arr_tmp;

~would that work?
~any other possibilities?

See the recent thread. What are you really trying to do? There may
be a simple answer for you problem.

OK, bad form, but it might cut down on the noise... I see, reading
Eric Sossman's reply, that I miss-read your code. I thought you were
using the int array for force alignment of a following declaration.
The other alignment thread is not relevant.

The pointer in 'arr' will be aligned for an int.

 

[anon.asdf]

(e-mail address removed) wrote On 08/28/07 10:49,:

1)
~Will "char arr[8]" always be 4-byte aligned (according to the natural
word size)???
~Or will it rather be 1-byte aligned (meaning it can lie where it
wants)???

The latter. Since `char' needs only 1-byte alignment,
the compiler does not need to align it more strictly.

(thinking ahead...) If not 4-byte aligned, but one desires a 4 byte
alignment, then one would have to use:
int arr_tmp[2];
char *arr = (char *)arr_tmp;

~would that work?

It would align the "`char' array" strictly enough for
an int. Under your assumption this means 4-byte alignment,
but that may not be true of all C implementations, or even
of all C implementatins where sizeof(int)==4.

~any other possibilities?

You can use a union to place objects of several types
at the same address, aligned well enough for the strictest
among them -- but it's not guaranteed that this will achieve
4-byte alignment.

just to put it into code (in case someone else is wondering)

union myunion {
char arr[8];
int arr_tmp[2];
};

union myunion uni = {{0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0, 1}};

char *arr = uni.arr;

You can acquire memory from malloc() et al., and this
will be aligned strictly enough for the most restrictive of
all C types (whatever that is). Again, this is not guaranteed
to have 4-byte alignment.

#include <stdlib.h>
#include <string.h>

#define LEN 9
{
char *arr = (char *) malloc(LEN);
memcpy(arr, (char[]) {0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0, 1, 2}, LEN);
free(arr);
}

A two-byte type requires either 2-byte or 1-byte
alignment. The compiler is not required to align it more
restrictively than the type needs.



See above. It's easy to get a group of objects aligned
so as to satisfy the strictest among them, but I can think
of no portable way to ensure 4-byte alignment.

union myunion2 {
short a;
int tmp;
};

union myunion2 mu2;
#define sh (mu2.a)

or

#include <stdlib.h>
#include <string.h>

#define sh (*sh_ptr)
{
short *sh_ptr = (short *) malloc(sizeof(short));
free(sh_ptr);
}

Thanks -Albert

 

[Bart van Ingen Schenau]

Hello!

Is it legal to access a 4-byte int at any offset (alignment) in the
following array:

No. You can only portably read a 4-byte int value from addresses that
are correctly aligned for reading such a value.

4 Questions:
* assume 32-bit processor: natural word size is 4 bytes
* alignment: a 4-byte int is aligned if it lies on an address that is
a multiple of 4

1)
~Will "char arr[8]" always be 4-byte aligned (according to the natural
word size)???
No.

~Or will it rather be 1-byte aligned (meaning it can lie where it
wants)???

Yes.
There are two important properties to alignment in C.
- The alignment requirements on an array are the same as those of the
element type of the array.
- The alignment requirements on a type T can not be stricter than the
size of the type (i.e. align_of(T) <= sizeof(T) ).
Because char is defined to have size 1, you must be able to place a
char object anywhere in the memory and the same holds for an array of
char.

(thinking ahead...) If not 4-byte aligned, but one desires a 4 byte
alignment, then one would have to use:
int arr_tmp[2];
char *arr = (char *)arr_tmp;

~would that work?

Yes, that would cause arr to point at 4-byte aligned memory.

~any other possibilities?

As Eric already indicated, unions and malloc().

2)
~Will "short sh;" (where short has 2 bytes) always be 4-byte aligned
(according to the natural word size)???
No.

~If not, and one desires it to be 4-byte aligned, one could use:
int tmp;
#define sh ( *((short *)(&tmp)) )

~would that work?

No. Casting an int* to a short* and dereferencing the result causes
Undefined Behaviour.

~are there any other possibilities?

Same as before. Use a union or malloc().

3)
*((int *) (arr + 1)) can be an unaligned 4-byte int-access (see
above). As can be seen above, it works with my gcc compiler. I believe
it splits into 2 accesses (that are then combined).
~Will it work on every standards-compliant C compiler (assuming int is
4 bytes)?

No. It will not even work on all platforms that GCC can produce code
for.

//That was a read.

//Now a write:
~ Is this legal:
int i;
*((int *)(arr+1)) = i;
? (It works with gcc!)
Does it depend on the C-compiler? Or on the processor? or...?

It depends very heavily on the processor.
Some processor have no alignment restrictions at all, so they can
access any type of object at any address.
Some processors impose a performance penalty for unaligned access.
Some processors simply do not allow unaligned access at all.

---- Offtopic: ----
Are there any good books that can be recommended on C programming and
in particular how this relates to the actual machine code generated?

Things like:
alignment, byte-ordering, portable C programming, how loops are
implemented in machine code, optimization

These books probably do exist, but they are by definition highly
platform/processor specific.

I wonder if reading the C standard is beneficial (or in what respect
it would be beneficial)?

Reading the standard can be beneficial if you want to know what is
guaranteed to be true across *all* platforms and C compilers.

Thanks -Albert

Bart v Ingen Schenau

 

[anon.asdf]

Thanks to Eric, Ben and Bart for the good explanations.

One last question:

Is a struct aligned according to its size, or according to the largest
component it contains:

Example:
What about a struct that has a sizeof 4 bytes, but contains at most a
2-byte short:
Will it be 2-byte short aligned? Or rather: will it be 4-byte aligned
since the whole structure has 4 bytes?

What if a struct contains a char-array of 4 elements? Will that be 4-
byte aligned or char aligned?

((Is this different with unions?))

No. Casting an int* to a short* and dereferencing the result causes
Undefined Behaviour.

OK that goes against what I expect from my processors!
Is it rare that this causes undefined behaviour? (Perhaps only on old
extremely limited processors...?)

Thanks -Albert

 

[anon.asdf]

One last question:

Is a struct aligned according to its size, or according to the largest
component it contains:

Example:
What about a struct that has a sizeof 4 bytes, but contains at most a
2-byte short:
Will it be 2-byte short aligned? Or rather: will it be 4-byte aligned
since the whole structure has 4 bytes?

What if a struct contains a char-array of 4 elements? Will that be 4-
byte aligned or char aligned?

((Is this different with unions?))

Relevant code snippets (if necessary) can be found (gnu.gcc.help)
here:
http://groups.google.com/group/gnu....b799e1b4117/2a1c268089b80017#2a1c268089b80017
-Albert

 

[Eric Sosman]

Thanks to Eric, Ben and Bart for the good explanations.

One last question:

Is a struct aligned according to its size, or according to the largest
component it contains:

Each element of the struct is correctly aligned within
the struct itself. This implies that the alignment requirements
of the elements must all be divisors of the struct's own
alignment requirement. Therefore, the struct's alignment
requirement is divisible by the least common multiple of its
elements' alignment requirements.

Often, the struct's alignment *is* the l.c.m. of the
element alignments, and since alignment requirements are
usually powers of two this means the struct's alignment is
the same as its strictest element's alignment. But C does
not guarantee this; all you can be sure of is that the struct
alignment is a multiple of the l.c.m.

Example:
What about a struct that has a sizeof 4 bytes, but contains at most a
2-byte short:
Will it be 2-byte short aligned? Or rather: will it be 4-byte aligned
since the whole structure has 4 bytes?

Its alignment requirement will be either 4, 2, or 1 byte.

What if a struct contains a char-array of 4 elements? Will that be 4-
byte aligned or char aligned?

Its alignment requirement will be either 4, 2, or 1 byte.

((Is this different with unions?))

Not in any way I can see. Just as with structs, a union must
be properly aligned for all its elements, so the union's alignment
is a multiple of the l.c.m. of the element alignments. Again, the
multiplier is often unity.

 

[anon.asdf]

Each element of the struct is correctly aligned within
the struct itself. This implies that the alignment requirements
of the elements must all be divisors of the struct's own
alignment requirement. Therefore, the struct's alignment
requirement is divisible by the least common multiple of its
elements' alignment requirements.

Thanks! (Elegantly worded - ...although I had to make up an example
for myself to fully understand it.)

Its alignment requirement will be either 4, 2, or 1 byte.

1 byte???
This implies that a 2-byte short can have an alignment requirement of
1 byte!
Hmmm...
That is probably a small typing error (because it would imply that
this 2-byte short can lie anywhere, even "edging" across the
processors "natural word divisions" - usually sizeof(int)), right?

If a 2-byte short has an alignment requirement of 2, and the struct
has 4 bytes,
then the struct will have an alignment requirement of 2, 4, etc.

Example:

struct mystruct {
short b;
char a;
char c;
};

OR

struct mystruct {
char a;
short b;
char c;
};
which
C will stuff as follows
struct mystruct {
char a;
char stuff1;
short b;
char c;
char stuff2;
};

Its alignment requirement will be either 4, 2, or 1 byte.

Yes, since the alignment req. of a char-array is 1 byte.


---

Here's something interesting:

struct structi {
short a; //2 bytes
int b; //4bytes
short c; //2bytes
} __attribute__ ((packed));

struct structi run_this_by_me_again;

Depending on how this is accessed
e.g.

*((int *)(((short*)&run_this_by_me_again)+1))
!!

it might be useful to have this struct aligned at addresses x for
which:
x%4 = 2
x mod 4 = 2

-- I'm going to post this at gnu.gcc.help to ask how such an alignment
can be achieved.

Albert

 

[Eric Sosman]

(e-mail address removed) wrote:
[...]

Example:
What about a struct that has a sizeof 4 bytes, but contains at most a
2-byte short:
Will it be 2-byte short aligned? Or rather: will it be 4-byte aligned
since the whole structure has 4 bytes?

Its alignment requirement will be either 4, 2, or 1 byte.

1 byte???
This implies that a 2-byte short can have an alignment requirement of
1 byte!
Hmmm...
That is probably a small typing error (because it would imply that
this 2-byte short can lie anywhere, even "edging" across the
processors "natural word divisions" - usually sizeof(int)), right?

No typing error: I wrote what I meant. On some machines,
a `short' can start at any address; on others, it must start
at an even address. On machines where sizeof(short) > 2 --
I don't know of any, but I know only a few of the zillions
of machines -- `short' might need even more restrictive
alignment.

If a 2-byte short has an alignment requirement of 2, and the struct
has 4 bytes,
then the struct will have an alignment requirement of 2, 4, etc.

Strike the "etc." A type's alignment requirement must
be a divisor of its size (otherwise, arrays of that type
wouldn't work). It follows that your four-byte struct cannot
require alignment stricter than four bytes. Considering the
divisibility requirement, a four-byte struct -- any four-
byte object, in fact -- must have an alignment requirement
of four, two, or one byte. Period. No threes, no eights.

Example:

struct mystruct {
short b;
char a;
char c;
};

OR

struct mystruct {
char a;
short b;
char c;
};
which
C will stuff as follows

s/will/may/
s/follows/it pleases/

struct mystruct {
char a;
char stuff1;
short b;
char c;
char stuff2;
};






Yes, since the alignment req. of a char-array is 1 byte.

"No," actually, because I overlooked something obvious.
Given `struct s { char c[4]; }' it is not guaranteed that
sizeof(struct s) == 4: there could be padding after the
array, making the struct larger than four bytes. In that
case, the alignment requirement would be some divisor of
that larger size. If sizeof(struct s) == 15, the alignment
requirement will be one of 1, 3, 5, or 15; 2 and 4 would
not be possibilities.

Here's something interesting:

struct structi {
short a; //2 bytes
int b; //4bytes
short c; //2bytes
} __attribute__ ((packed));

As has been suggested before, you should ask about
gcc-specific extensions to C in a gcc-specific forum,
not here.

 

[anon.asdf]

(e-mail address removed) wrote On 08/29/07 10:46,:

That is probably a small typing error (because it would imply that
this 2-byte short can lie anywhere, even "edging" across the
processors "natural word divisions" - usually sizeof(int)), right?

No typing error: I wrote what I meant. On some machines,
a `short' can start at any address; [...]

Even a 2-byte short?

Strike the "etc." A type's alignment requirement must
be a divisor of its size (otherwise, arrays of that type
wouldn't work). It follows that your four-byte struct cannot
require alignment stricter than four bytes. Considering the
divisibility requirement, a four-byte struct -- any four-
byte object, in fact -- must have an alignment requirement
of four, two, or one byte. Period. No threes, no eights.

Makes sense, thanks.

After all this, here's my personal definition:

(Assuming byte-adresses
A structure has an alignment requirement of X bytes, if it can lie at
addresses y, such that:
y%X = 0
y mod X = 0

So for structs, one can define: A (unpacked **) struct has an
alignment requirement of X bytes,
where X is a divisor of the structure's size in bytes. X itself must
be divisible by the "the least common multiple of the structure's
elements' alignment requirements" (in bytes).

All of the structure's elements have to satisfy their alignment req.,
so that padding is added where necessary:

Only if the structure is padded like that, can it be guaranteed, that
the structure's size is a multiple of "the least common multiple of
the structure's elements' alignment requirements":
(Only then can an X satisfying the above conditions be found.)

Even when all the elements are already correctly aligned, additional
padding could still be added, but it must be padded, such that an X
satisfying the above conditions can be found (must exist).

(unpacked **) - above means: padded where necessary

-Albert

 

[Eric Sosman]

(e-mail address removed) wrote On 08/29/07 10:46,:

That is probably a small typing error (because it would imply that
this 2-byte short can lie anywhere, even "edging" across the
processors "natural word divisions" - usually sizeof(int)), right?

No typing error: I wrote what I meant. On some machines,
a `short' can start at any address; [...]

Even a 2-byte short?

Yes. Even an N-byte short.

 

[Peter J. Holzer]

No typing error: I wrote what I meant. On some machines,
a `short' can start at any address;

"anon.asdf" probably has such a machine: The Intel x86 processor doesn't
need any alignment on any of its data types. Accessing aligned data is a
bit faster than accessing unaligned data, which is why compilers usually
align 16 bit types on even addresses, 32 bit types on addresses
dividable by 4, etc. But from a functional POV that isn't necessary, and
I think "1 byte alignment for everything" was even the default for some
8086 compilers.

hp

 

[Richard Bos]

(e-mail address removed) wrote:
[...]
Example:
What about a struct that has a sizeof 4 bytes, but contains at most a
2-byte short:
Will it be 2-byte short aligned? Or rather: will it be 4-byte aligned
since the whole structure has 4 bytes?

Its alignment requirement will be either 4, 2, or 1 byte.

1 byte???
This implies that a 2-byte short can have an alignment requirement of
1 byte!
Hmmm...
That is probably a small typing error (because it would imply that
this 2-byte short can lie anywhere, even "edging" across the
processors "natural word divisions" - usually sizeof(int)), right?

No typing error: I wrote what I meant. On some machines,
a `short' can start at any address; on others, it must start
at an even address.

And there could even be - but probably are not right now - machines
where it must start at an odd address.

Richard

 

[Keith Thompson]

And there could even be - but probably are not right now - machines
where it must start at an odd address.

But not if any other type must start at an even address.

 

[Richard Bos]

But not if any other type must start at an even address.

True. Unless the compiler hacks accesses to shorts which start structs
around like nobody's business, but that's even less likely.

Richard

 

[Keith Thompson]

True. Unless the compiler hacks accesses to shorts which start structs
around like nobody's business, but that's even less likely.

It's impossible. Suppose short requires an odd address, and int
requires an even addresss. Then there's no way to allocate an object
of type 'union { short s; int i; }', or to allocate both shorts and
ints via malloc.

If the compiler works around the alignment restriction by, say,
accessing shorts a byte at a time, then shorts don't require odd
addresses.

What is possible, assuming the hardware imposes such odd (ahem)
requirements, is that the compiler can allocate shorts at odd
addresses whenever it can, and put them at even addresses only when
necessary. The *preferred* alignment for a given type may differ from
the *required* alignment for that same type.

On any hardware, it's possible for the compiler to impose only byte
alignment on all types, as long as it generates the (possibly slow and
bulky) code necessary to deal with this.

 

[Richard Tobin]

And there could even be - but probably are not right now - machines
where it must start at an odd address.

But the C standard does not allow for this: its concept of alignment is
the requirement that an object of a given type start at a multiple of
some particular number of bytes.

-- Richard

 

[CBFalconer]

But the C standard does not allow for this: its concept of
alignment is the requirement that an object of a given type start
at a multiple of some particular number of bytes.

Chapter and verse please. I think you can come to this conclusion
only by making some earlier assumptions about the memory system.
AFAIK the only stricture is that malloc returns an address aligned
for ALL types.