Allocating memory aligned on a given boundary

[K. Jennings]

I would like to get the result of malloc() such that it is
aligned on a given boundary - 8, in this case. Assuming that sizeof(u64)
is 8, will

u64 *p = malloc(N) ;

do the trick in general?

Here N is a positive integer, and I am assuming that malloc()
succeeds in allocating the chunk of memory specified.

This seems to work, but I do not know whether it is just my
compiler, or a general rule in C.

[Richard Heathfield]

K. Jennings said:

I would like to get the result of malloc() such that it is
aligned on a given boundary - 8, in this case. Assuming that
sizeof(u64) is 8, will

u64 *p = malloc(N) ;

do the trick in general?

The C Standard guarantees that malloc's result (if not NULL) is always
correctly aligned for any object type.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Walter Roberson]

In article <7K******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>K. Jennings said:

>I would like to get the result of malloc() such that it is
aligned on a given boundary - 8, in this case. Assuming that
sizeof(u64) is 8, will

>u64 *p = malloc(N) ;

>do the trick in general?

>The C Standard guarantees that malloc's result (if not NULL) is always
correctly aligned for any object type.

Expanding slightly:

This means that if the particular implementation is able and
willing to handle u64's (and everything else) on (say) 4 byte boundaries,
then malloc(sizeof u64) is not guaranteed to be aligned on a multiple
of sizeof u64. The guarantee is only that it will be allocated on
an accessible boundary. The difference between accessible boundaries
and specific alignment boundaries (e.g., 8) can sometimes be of
concern, such as if you are trying to take into account cache effects.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Flash Gordon]

Richard Heathfield wrote, On 24/04/07 17:41:

K. Jennings said:

>I would like to get the result of malloc() such that it is
aligned on a given boundary - 8, in this case. Assuming that
sizeof(u64) is 8, will

u64 *p = malloc(N) ;

do the trick in general?

The C Standard guarantees that malloc's result (if not NULL) is always
correctly aligned for any object type.

However it makes no guarantees about what the alignment might be nor any
way to find out. So if you really want a specific alignment, for example
so that you can use some highly system specific tricks, you will need to
use some highly system specific method. Any such methods and tricks
would be off topic here so you would have to ask in a group dealing with
the specific platform(s) of interest.
--
Flash Gordon

[Army1987]

"K. Jennings" <kj*******@resurgence.netha scritto nel messaggio
news:pa*********************@resurgence.net...

I would like to get the result of malloc() such that it is
aligned on a given boundary - 8, in this case. Assuming that sizeof(u64)
is 8, will

u64 *p = malloc(N) ;

do the trick in general?

Here N is a positive integer, and I am assuming that malloc()
succeeds in allocating the chunk of memory specified.

Is the real question "What happens if N isn't a multiple of 8?"?

[K. Jennings]

On Tue, 24 Apr 2007 21:26:05 +0200, Army1987 wrote:

"K. Jennings" <kj*******@resurgence.netha scritto nel messaggio
news:pa*********************@resurgence.net...

>I would like to get the result of malloc() such that it is aligned on a
given boundary - 8, in this case. Assuming that sizeof(u64) is 8, will

u64 *p = malloc(N) ;

do the trick in general?

Here N is a positive integer, and I am assuming that malloc() succeeds
in allocating the chunk of memory specified.

Is the real question "What happens if N isn't a multiple of 8?"?

No. The actual value of N is irrelevant, as far as that is
concerned.

[Eric Sosman]

K. Jennings wrote On 04/24/07 15:43,:

On Tue, 24 Apr 2007 21:26:05 +0200, Army1987 wrote:

>>"K. Jennings" <kj*******@resurgence.netha scritto nel messaggio
news:pa*********************@resurgence.net...

>>>I would like to get the result of malloc() such that it is aligned on a
given boundary - 8, in this case. Assuming that sizeof(u64) is 8, will

u64 *p = malloc(N) ;

do the trick in general?

Here N is a positive integer, and I am assuming that malloc() succeeds
in allocating the chunk of memory specified.

Is the real question "What happens if N isn't a multiple of 8?"?

No. The actual value of N is irrelevant, as far as that is
concerned.

Are you still seeking answers, and if so, to what?
To summarize what's appeared thus far: A successful malloc()
allocates memory that is suitably aligned for all C data
types (but not necessarily for non-C "types" like "pages"),
and there is no portable way to discover what the "suitable
for all types" alignment requirement is, nor even to discover
the alignment of any particular allocation. Does this answer
your question, or is there something else you hope to learn?

--
Er*********@sun.com

[K. Jennings]

On Tue, 24 Apr 2007 16:49:14 -0400, Eric Sosman wrote:

K. Jennings wrote On 04/24/07 15:43,:

>On Tue, 24 Apr 2007 21:26:05 +0200, Army1987 wrote:

>>>"K. Jennings" <kj*******@resurgence.netha scritto nel messaggio
news:pa*********************@resurgence.net.. .

I would like to get the result of malloc() such that it is aligned on
a given boundary - 8, in this case. Assuming that sizeof(u64) is 8,
will

u64 *p = malloc(N) ;

do the trick in general?

Here N is a positive integer, and I am assuming that malloc() succeeds
in allocating the chunk of memory specified.

Is the real question "What happens if N isn't a multiple of 8?"?

No. The actual value of N is irrelevant, as far as that is
concerned.

Are you still seeking answers, and if so, to what?
To summarize what's appeared thus far: A successful malloc() allocates
memory that is suitably aligned for all C data types (but not
necessarily for non-C "types" like "pages"), and there is no portable
way to discover what the "suitable for all types" alignment requirement
is, nor even to discover the alignment of any particular allocation.
Does this answer your question, or is there something else you hope to
learn?

I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do

u64 *p = malloc(N) ;

or

char *p = malloc(N) ;

the address returned, when non-NULL, will be aligned on a boundary equal
to the largest basic data size supported. Thus, for 32-bit architectures
it might be either 4 or 8 bytes, whereas for 64-bit ones it would be 8.
Or am I missing something?

[Ian Collins]

K. Jennings wrote:

On Tue, 24 Apr 2007 16:49:14 -0400, Eric Sosman wrote:

>>K. Jennings wrote On 04/24/07 15:43,:

>>>On Tue, 24 Apr 2007 21:26:05 +0200, Army1987 wrote:

"K. Jennings" <kj*******@resurgence.netha scritto nel messaggio
news:pa*********************@resurgence.net. ..
>I would like to get the result of malloc() such that it is aligned on
>a given boundary - 8, in this case. Assuming that sizeof(u64) is 8,
>will
>
>u64 *p = malloc(N) ;
>
>do the trick in general?
>
>Here N is a positive integer, and I am assuming that malloc() succeeds
>in allocating the chunk of memory specified.

Is the real question "What happens if N isn't a multiple of 8?"?
No. The actual value of N is irrelevant, as far as that is
concerned.

Are you still seeking answers, and if so, to what?
To summarize what's appeared thus far: A successful malloc() allocates
memory that is suitably aligned for all C data types (but not
necessarily for non-C "types" like "pages"), and there is no portable
way to discover what the "suitable for all types" alignment requirement
is, nor even to discover the alignment of any particular allocation.
Does this answer your question, or is there something else you hope to
learn?

I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do

u64 *p = malloc(N) ;

or

char *p = malloc(N) ;

the address returned, when non-NULL, will be aligned on a boundary equal
to the largest basic data size supported. Thus, for 32-bit architectures
it might be either 4 or 8 bytes, whereas for 64-bit ones it would be 8.
Or am I missing something?

Or it might be something else if there is a bigger type (long double for
example). On my boxes, the alignment is 16 on 32 and 64 bit
(sizeof(long double) == 12 ).

--
Ian Collins.

[Richard Bos]

"K. Jennings" <kj*******@resurgence.netwrote:

I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do

u64 *p = malloc(N) ;

or

char *p = malloc(N) ;

the address returned, when non-NULL, will be aligned on a boundary equal
to the largest basic data size supported.

No, it will be aligned at least on the strictest required alignment
boundary. Often, that will be the same as the largest basic type size,
but that's not necessarily true. For example...

Thus, for 32-bit architectures it might be either 4 or 8 bytes, whereas
for 64-bit ones it would be 8.

....that 8-byte type might only need an alignment of 4 bytes, i.e., it
could be legally aligned on boundaries that are only half its own size
apart.
On some systems, there might not be any alignment requirements at all.
All objects, regardless of size, could be located anywhere in memory. On
that system, malloc() could return pointers at any position.
OTOH, on some systems, malloc() could return pointers that are more
widely aligned than the most restrictive basic type needs. Apart from a
requirement of the underlying hardware, I cannot think of any good
reason why it should, but you can't assume that it doesn't.

And then there are the _really_ wild systems, where long ints are 4
bytes but doubles are 5 bytes, and void *s 7... in which case, malloc()
would need to return pointers aligned to 4*5*7==140 byte boundaries. I
don't know of any example of this in practice, but it could exist, there
might be good reasons for it to exist, and the Standard doesn't forbid
it. So really, my first sentence in this post should be "No, it will be
aligned to the least common multiple of all basic object type sizes".

Richard

[Eric Sosman]

K. Jennings wrote:

[...]

I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do

u64 *p = malloc(N) ;

or

char *p = malloc(N) ;

the address returned, when non-NULL, will be aligned on a boundary equal
to the largest basic data size supported. Thus, for 32-bit architectures
it might be either 4 or 8 bytes, whereas for 64-bit ones it would be 8.
Or am I missing something?

You're right about the first part: The memory is suitably
aligned for any C data type whatsoever. But you stray from the
Tao beginning at "Thus." The alignment requirement for type T
must be a divisor of sizeof(T) (otherwise arrays wouldn't work),
but need not be equal to sizeof(T).

For your 64-bit data type (assuming an 8-bit char), the
alignment requirement might be any of 1,2,4, or 8.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Eric Sosman]

K. Jennings wrote:

[...]

I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do

u64 *p = malloc(N) ;

or

char *p = malloc(N) ;

the address returned, when non-NULL, will be aligned on a boundary equal
to the largest basic data size supported. Thus, for 32-bit architectures
it might be either 4 or 8 bytes, whereas for 64-bit ones it would be 8.
Or am I missing something?

Earlier I wrote that you were "right about the first part,"
but I'd read too hastily. The non-NULL malloc() result will
meet the *alignment requirement* of all C types, which might
be smaller than the sizeof's one or more basic types. Alignment
divides sizeof, but need not be equal to it.

(Memo to self: Allow coffee to take hold before posting.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[Kenneth Brody]

"K. Jennings" wrote:

>
On Tue, 24 Apr 2007 16:49:14 -0400, Eric Sosman wrote:

[...]

Are you still seeking answers, and if so, to what?
To summarize what's appeared thus far: A successful malloc() allocates
memory that is suitably aligned for all C data types (but not
necessarily for non-C "types" like "pages"), and there is no portable
way to discover what the "suitable for all types" alignment requirement
is, nor even to discover the alignment of any particular allocation.
Does this answer your question, or is there something else you hope to
learn?

I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do

u64 *p = malloc(N) ;

or

char *p = malloc(N) ;

the address returned, when non-NULL, will be aligned on a boundary equal
to the largest basic data size supported. Thus, for 32-bit architectures
it might be either 4 or 8 bytes, whereas for 64-bit ones it would be 8.
Or am I missing something?

All that's guaranteed is that it's _properly_aligned_ for any type.
This does not necessarily mean that it is, using your example,
aligned to sizeof(longest_type). You may have a 64-bit "long long"
type, yet still get 4-byte (ie: 32-bit) alignment. The alignment
may also be larger than the minimum needed by the hardware. For
example, my system returns 8-byte alignment, even though the
hardware itself would be happy with 2-byte alignment (and happier
with 4-byte alignment). This is simply because the implementation
decided to do so for its own convenience, as it allows it to use
the low-order 3 bits of pointers within the heap for its own use.
Also, way back in MS-DOS days, I used an implementation which
returned 16-byte alignment, even though 1-byte alignment would
have sufficed. This allowed malloc's "far pointers" to always
have a zero offset, as I recall. (Another great reason for
making sure you include the correct headers, as without the
proper return type declared, the assumption of "int" would have
meant you would always see a zero return.)

As others have stated, there is no portable way to know what the
alignment is. Nor is there likely any need to know, as all you
really should care about is that the alignment is valid. (Unless
you are writing your own malloc, and you need to know that you
are implementing it correctly.)

Why do you think you need to determine malloc's alignment?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

Richard Bos wrote:
[...]

OTOH, on some systems, malloc() could return pointers that are more
widely aligned than the most restrictive basic type needs. Apart from a
requirement of the underlying hardware, I cannot think of any good
reason why it should, but you can't assume that it doesn't.

[...]

I have seen such implementations (ie: 8-byte alignment from malloc,
despite only needing 2- or 4-byte alignment). In those cases, the
heap was managed with a singly-linked list, and within the header
of each chunk of the heap was a "next" pointer. (Or maybe it was
"block length"?) In any case, the low-order 3 bits of these values
were used for some internal status flags, as the actual value was
guaranteed to have the low-order 3 bits as zero.

Also, way back in MS-DOS days, the compiler I used had 16-byte
alignment for malloc. This meant it could guarantee that the
segment:offset value returned (in "large mode") would always have
a zero offset.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalidwrites:

K. Jennings wrote:

>[...]
I think I have the info that I wanted. If I understand it
correctly, it makes no difference whether you do
u64 *p = malloc(N) ;
or
char *p = malloc(N) ;
the address returned, when non-NULL, will be aligned on a boundary
equal to the largest basic data size supported. Thus, for 32-bit
architectures it might be either 4 or 8 bytes, whereas for 64-bit
ones it would be 8. Or am I missing something?

You're right about the first part: The memory is suitably
aligned for any C data type whatsoever. But you stray from the
Tao beginning at "Thus." The alignment requirement for type T
must be a divisor of sizeof(T) (otherwise arrays wouldn't work),
but need not be equal to sizeof(T).

For your 64-bit data type (assuming an 8-bit char), the
alignment requirement might be any of 1,2,4, or 8.

But he said "32-bit architectures", not "32-bit types". A system with
a 32-bit architecture could require 1, 2, 4, or 8-byte alignment for a
64-bit type (again assuming CHAR_BIT==8).

Of course the phrases "32-bit architecture" and "64-bit architecture"
are very vaguely defined, and neither necessarily implies any specific
alignment requirements.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Doug]

On 24 Apr, 21:49, Eric Sosman <[e-mail]:

K. Jennings wrote On 04/24/07 15:43,:

On Tue, 24 Apr 2007 21:26:05 +0200, Army1987 wrote:

>"K. Jennings" <[e-mail] scritto nel messaggio
news:pa*********************@resurgence.net...

>>I would like to get the result of malloc() such that it is aligned on a
given boundary - 8, in this case. Assuming that sizeof(u64) is 8, will

>>u64 *p = malloc(N) ;

>>do the trick in general?

>>Here N is a positive integer, and I am assuming that malloc() succeeds
in allocating the chunk of memory specified.

>Is the real question "What happens if N isn't a multiple of 8?"?

No. The actual value of N is irrelevant, as far as that is
concerned.

Are you still seeking answers, and if so, to what?
To summarize what's appeared thus far: A successful malloc()
allocates memory that is suitably aligned for all C data
types (but not necessarily for non-C "types" like "pages"),
and there is no portable way to discover what the "suitable
for all types" alignment requirement is, nor even to discover
the alignment of any particular allocation. Does this answer
your question, or is there something else you hope to learn?

No, I think you've patronised him enough.

[CBFalconer]

Eric Sosman wrote:

>

.... snip ...

>
You're right about the first part: The memory is suitably
aligned for any C data type whatsoever. But you stray from the
Tao beginning at "Thus." The alignment requirement for type T
must be a divisor of sizeof(T) (otherwise arrays wouldn't work),
but need not be equal to sizeof(T).

That depends on the hardware. Some just don't care.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline.net

--
Posted via a free Usenet account from http://www.teranews.com

[Dave Vandervies]

In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Eric Sosman wrote:

>>

... snip ...

>>
You're right about the first part: The memory is suitably
aligned for any C data type whatsoever. But you stray from the
Tao beginning at "Thus." The alignment requirement for type T
must be a divisor of sizeof(T) (otherwise arrays wouldn't work),
but need not be equal to sizeof(T).

That depends on the hardware. Some just don't care.

If the hardware doesn't care, then the alignment requirement is 1 byte,
which divides sizeof(T) for any T.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I don't know what happens when you buy a car, but it must
be DEBILITATING. CRIPPLING.
--Maarten Wiltink in the scary devil monastery

[Eric Sosman]

Doug wrote:

On 24 Apr, 21:49, Eric Sosman <[e-mail]:

>K. Jennings wrote On 04/24/07 15:43,:

>>On Tue, 24 Apr 2007 21:26:05 +0200, Army1987 wrote:
"K. Jennings" <[e-mail] scritto nel messaggio
news:pa*********************@resurgence.net.. .
I would like to get the result of malloc() such that it is aligned on a
given boundary - 8, in this case. Assuming that sizeof(u64) is 8, will
u64 *p = malloc(N) ;
do the trick in general?
Here N is a positive integer, and I am assuming that malloc() succeeds
in allocating the chunk of memory specified.
Is the real question "What happens if N isn't a multiple of 8?"?
No. The actual value of N is irrelevant, as far as that is
concerned.

Are you still seeking answers, and if so, to what?
To summarize what's appeared thus far: A successful malloc()
allocates memory that is suitably aligned for all C data
types (but not necessarily for non-C "types" like "pages"),
and there is no portable way to discover what the "suitable
for all types" alignment requirement is, nor even to discover
the alignment of any particular allocation. Does this answer
your question, or is there something else you hope to learn?

No, I think you've patronised him enough.

It was an honest question: The answers seemed to have been
given and validated, yet the discussion carried on (and with the
O.P.'s participation). Why? Was there, perhaps, an unstated
question lurking somewhere in the background, or a confusion
about some aspect of the answers? That's why I asked, much as
the butlers in those drawing-room comedies ask "Will there be
anything else, m'lud?"

... and as it turned out, the O.P. *was* still confused a
bit about the distinction between sizeof and alignment, so my
prompting was not entirely wasted. (What was wasted was my
next response, a miracle of misreading and sloppy composition.
Ah, well, that's Usenet: Advice worth every penny paid.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

Dave Vandervies wrote:

CBFalconer <cb********@maineline.netwrote:

>Eric Sosman wrote:

>>>

... snip ...

>>>
You're right about the first part: The memory is suitably
aligned for any C data type whatsoever. But you stray from the
Tao beginning at "Thus." The alignment requirement for type T
must be a divisor of sizeof(T) (otherwise arrays wouldn't work),
but need not be equal to sizeof(T).

That depends on the hardware. Some just don't care.

If the hardware doesn't care, then the alignment requirement is
1 byte, which divides sizeof(T) for any T.

Not necessarily. The compiler may be adjusting for speed reasons.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

CBFalconer wrote:

Dave Vandervies wrote:

>CBFalconer <cb********@maineline.netwrote:

>>Eric Sosman wrote:
... snip ...
You're right about the first part: The memory is suitably
aligned for any C data type whatsoever. But you stray from the
Tao beginning at "Thus." The alignment requirement for type T
must be a divisor of sizeof(T) (otherwise arrays wouldn't work),
but need not be equal to sizeof(T).
That depends on the hardware. Some just don't care.

If the hardware doesn't care, then the alignment requirement is
1 byte, which divides sizeof(T) for any T.

Not necessarily. The compiler may be adjusting for speed reasons.

.... in which case it's imposing an alignment requirement that
isn't forced upon it by the hardware. There's nothing wrong
with that; nowhere does the Standard say that alignment must
be dictated by the hardware alone.

Whatever the alignment requirement and whatever the reason
for imposing it, it must be an exact divisor of sizeof(T).

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

Eric Sosman wrote:

CBFalconer wrote:

.... snip ...

>>
Not necessarily. The compiler may be adjusting for speed reasons.

... in which case it's imposing an alignment requirement that
isn't forced upon it by the hardware. There's nothing wrong
with that; nowhere does the Standard say that alignment must
be dictated by the hardware alone.

Whatever the alignment requirement and whatever the reason
for imposing it, it must be an exact divisor of sizeof(T).

Disagree. Consider an x86 in native mode. The address buss is 20
bits. But the internal code only handles 16 bit quantities.
Addresses are composed of two parts, the segment register and the
offset. Access is equally fast for any 16 bit alignment, because
the data buss is 16 bits. Yet code can be written to handle 32 bit
objects.

Not the prime object of compilation today, but it exists.

Then there is Vista. See below:
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

CBFalconer wrote On 04/27/07 09:44,:

Eric Sosman wrote:

>>CBFalconer wrote:

... snip ...

>>>Not necessarily. The compiler may be adjusting for speed reasons.

... in which case it's imposing an alignment requirement that
isn't forced upon it by the hardware. There's nothing wrong
with that; nowhere does the Standard say that alignment must
be dictated by the hardware alone.

Whatever the alignment requirement and whatever the reason
for imposing it, it must be an exact divisor of sizeof(T).

Disagree. Consider an x86 in native mode. The address buss is 20
bits. But the internal code only handles 16 bit quantities.
Addresses are composed of two parts, the segment register and the
offset. Access is equally fast for any 16 bit alignment, because
the data buss is 16 bits. Yet code can be written to handle 32 bit
objects.

Not the prime object of compilation today, but it exists.

None of this seems to have anything to do with alignment
requirements. Maybe that's due to my unfamiliarity with x86,
but I don't see any connection between the way sixteen-bit
quantities are combined into twenty or thirty-two bits, and
the ways all those things must be aligned.

In hopes of clearing things up -- maybe we're using the
same words to talk about different things -- here's what I
mean when I say the alignment requirement for type T is a
divisor of sizeof(T):

Begin with the Standard's definition in Section 3.2:

alignment
requirement that objects of a particular type be
located on storage boundaries with addresses that
are particular multiples of a byte address

This definition has a number of implications. The
reference to "multiples" of a byte address implies that an
address can be multiplied by something. The address might
not be entirely numeric -- we can imagine a machine with
addresses like (Blue,42) and (Red,18) -- but there must
be some way to multiply an address by some quantity.

I am going to assume that the "some quantity" is an
integer, so we can compute 2*(Blue,42) -(Mauve,84).
If the multiplying quantity is something else -- a complex
number, or a member of the set {Sweet,Sour,Bitter,Salty} --
then my assertion that alignment divides sizeof comes
unglued and I concede your objection. (I'd hate to debug
on such a machine, though!)

So: If we read "multiples" as "integer multiples,"
we are also led to the conclusion that alignment amounts
to a divisibility condition. An object of type T is
properly aligned if it is situated at an address that is
divisible by some integer A(T), written thus to emphasize
that the value may depend on the type T; different types
can have different alignment requirements.

What can we learn about A(T)? Consider an array of
two T objects: `T x[2];'. We know that x[0] is properly
aligned as a T object, and so is x[1]. Therefore, their
byte addresses (char*)&x[0] and (char*)&x[1] are both
multiples of A(T), both divisible by A(T). How far apart
are these two addresses? They are

ptrdiff_t D = (char*)x[1] - (char*)x[0];

bytes apart. And by the way arrays work, this value D is
exactly sizeof(T).

Since the two values (char*)&x[0] and (char*)&x[1]
are both divisible by A(T), their difference D = sizeof(T)
is also divisible by A(T). That is, alignment divides
sizeof -- at least, on machines where "multiples" are of
integers and not of objects from bizarre sets. (The
argument holds even if the addresses themselves are bizarre,
as long as the multipliers are taken to be integers.)

Then there is Vista. See below:

I confess I did not study the four references, but at
a brief glance none of them seemed to concern the alignment
of C data types. The first (which I'd seen before) was an
analysis of the Vista's content protection, the second was
about licensing, the third and fourth were anti-Vista
broadsides. All possibly justifiable, but none seeming to
bear on the question at hand. If there's something about
alignment in these four papers, perhaps you could point out
the specific passages you have in mind.

--
Er*********@sun.com

[Eric Sosman]

Eric Sosman wrote On 04/27/07 11:57,:

[...] Consider an array of
two T objects: `T x[2];'. We know that x[0] is properly
aligned as a T object, and so is x[1]. Therefore, their
byte addresses (char*)&x[0] and (char*)&x[1] are both
multiples of A(T), both divisible by A(T). How far apart
are these two addresses? They are

ptrdiff_t D = (char*)x[1] - (char*)x[0];

Drat! I left out the address-of operators:

ptrdiff_t D = (char*)&x[1] - (char*)&x[0];

.... as in the text. Sorry.

--
Er*********@sun.com

[CBFalconer]

Eric Sosman wrote:

CBFalconer wrote On 04/27/07 09:44,:

>Eric Sosman wrote:

>>CBFalconer wrote:

... snip ...

>>>Not necessarily. The compiler may be adjusting for speed reasons.

... in which case it's imposing an alignment requirement that
isn't forced upon it by the hardware. There's nothing wrong
with that; nowhere does the Standard say that alignment must
be dictated by the hardware alone.

Whatever the alignment requirement and whatever the reason
for imposing it, it must be an exact divisor of sizeof(T).

Disagree. Consider an x86 in native mode. The address buss is 20
bits. But the internal code only handles 16 bit quantities.
Addresses are composed of two parts, the segment register and the
offset. Access is equally fast for any 16 bit alignment, because
the data buss is 16 bits. Yet code can be written to handle 32 bit
objects.

Not the prime object of compilation today, but it exists.

None of this seems to have anything to do with alignment
requirements. Maybe that's due to my unfamiliarity with x86,
but I don't see any connection between the way sixteen-bit
quantities are combined into twenty or thirty-two bits, and
the ways all those things must be aligned.

In hopes of clearing things up -- maybe we're using the
same words to talk about different things -- here's what I
mean when I say the alignment requirement for type T is a
divisor of sizeof(T):

Begin with the Standard's definition in Section 3.2:

alignment
requirement that objects of a particular type be
located on storage boundaries with addresses that
are particular multiples of a byte address

This definition has a number of implications. The
reference to "multiples" of a byte address implies that an
address can be multiplied by something. The address might
not be entirely numeric -- we can imagine a machine with
addresses like (Blue,42) and (Red,18) -- but there must
be some way to multiply an address by some quantity.

All I am objecting to is the "multiple of sizeof" phrase, and I
illustrated a case. In your example we can assume that a multiple
operates only on the offset value, for example. There is no need
to go any further than whatever minimizes the memory access time,
and possibly not even that if we don't care about speed. All the
thing has to do is work.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

CBFalconer wrote On 04/27/07 15:18,:

Eric Sosman wrote:

>[... too much ...]

All I am objecting to is the "multiple of sizeof" phrase, and I
illustrated a case. In your example we can assume that a multiple
operates only on the offset value, for example. There is no need
to go any further than whatever minimizes the memory access time,
and possibly not even that if we don't care about speed. All the
thing has to do is work.

Your point still escapes me. I didn't use the phrase
"multiple of sizeof" -- or if I did, it was a typo and I'm
still overlooking it. I said (or meant to say) that the
alignment requirement for a type is a *divisor* of its
sizeof, which is 'tother way about.

--
Er*********@sun.com

[Kenneth Brody]

CBFalconer wrote:

>
Eric Sosman wrote:

[...]

Whatever the alignment requirement and whatever the reason
for imposing it, it must be an exact divisor of sizeof(T).

Disagree. Consider an x86 in native mode. The address buss is 20
bits. But the internal code only handles 16 bit quantities.
Addresses are composed of two parts, the segment register and the
offset. Access is equally fast for any 16 bit alignment, because
the data buss is 16 bits. Yet code can be written to handle 32 bit
objects.

[...]

So, sizeof(long)==4, and the alignment is 2. Two is an exact
divisor of 4. Where's the disagreement?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Eric Sosman wrote:

>CBFalconer wrote:

... snip ...

>>>
Not necessarily. The compiler may be adjusting for speed reasons.

... in which case it's imposing an alignment requirement that
isn't forced upon it by the hardware. There's nothing wrong
with that; nowhere does the Standard say that alignment must
be dictated by the hardware alone.

Whatever the alignment requirement and whatever the reason
for imposing it, it must be an exact divisor of sizeof(T).

Disagree. Consider an x86 in native mode. The address buss is 20
bits. But the internal code only handles 16 bit quantities.
Addresses are composed of two parts, the segment register and the
offset. Access is equally fast for any 16 bit alignment, because
the data buss is 16 bits. Yet code can be written to handle 32 bit
objects.

If 16 bits is no longer an exact divisor of 32 bits, nobody told me
about it. (Perhaps you thought he meant multiple rather than
divisor?)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Eric Sosman wrote:

CBFalconer wrote On 04/27/07 15:18,:

>>
[... too much ...]

All I am objecting to is the "multiple of sizeof" phrase, and I
illustrated a case. In your example we can assume that a multiple
operates only on the offset value, for example. There is no need
to go any further than whatever minimizes the memory access time,
and possibly not even that if we don't care about speed. All the
thing has to do is work.

Your point still escapes me. I didn't use the phrase
"multiple of sizeof" -- or if I did, it was a typo and I'm
still overlooking it. I said (or meant to say) that the
alignment requirement for a type is a *divisor* of its
sizeof, which is 'tother way about.

Your quotation did:

requirement that objects of a particular type be
located on storage boundaries with addresses that
are particular multiples of a byte address

But now I can agree with you :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Eric Sosman wrote:

>CBFalconer wrote On 04/27/07 15:18,:

>>>
[... too much ...]

All I am objecting to is the "multiple of sizeof" phrase, and I
illustrated a case. In your example we can assume that a multiple
operates only on the offset value, for example. There is no need
to go any further than whatever minimizes the memory access time,
and possibly not even that if we don't care about speed. All the
thing has to do is work.

Your point still escapes me. I didn't use the phrase
"multiple of sizeof" -- or if I did, it was a typo and I'm
still overlooking it. I said (or meant to say) that the
alignment requirement for a type is a *divisor* of its
sizeof, which is 'tother way about.

Your quotation did:

requirement that objects of a particular type be
located on storage boundaries with addresses that
are particular multiples of a byte address

But now I can agree with you :-)

That quotation is the standard's definition of "alignment", C99 3.2p1.
It doesn't say anything about multiple of sizeof, just "multiples of a
byte address" (a phrase that doesn't make a whole lot of sense unless
you already understand what it's *supposed* to mean).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"