How does malloc align pointer

[junky_fellow]

The standard says that,
The pointer returned by malloc(), if the allocation
succeeds is suitably aligned so that it may be assigned to a
pointer to any type of object.

Since, the alignment cannot be done portably, is that mean
that malloc is implementation specific ? The malloc()
written for one implementation may not be work on other
implementations ?

Also, how does malloc() determine, which pointer type has the most
strict alignment storage restrictions ? Because it has to return
a pointer that would always be aligned to the pointer type that
has most strict alignment storage restriction.

[Keith Thompson]

ju**********@yahoo.co.in writes:

The standard says that,
The pointer returned by malloc(), if the allocation
succeeds is suitably aligned so that it may be assigned to a
pointer to any type of object.
Right.
Since, the alignment cannot be done portably, is that mean
that malloc is implementation specific ? The malloc()
written for one implementation may not be work on other
implementations ?
Exactly.
Also, how does malloc() determine, which pointer type has the most
strict alignment storage restrictions ? Because it has to return
a pointer that would always be aligned to the pointer type that
has most strict alignment storage restriction.

The person who writes the malloc() function has to know enough about
the compiler to know what alignment is required.

--
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.

[Chris Dollin]

ju**********@yahoo.co.in wrote:

The standard says that,
The pointer returned by malloc(), if the allocation
succeeds is suitably aligned so that it may be assigned to a
pointer to any type of object.

Since, the alignment cannot be done portably, is that mean
that malloc is implementation specific ?
Yes. (Which is one reason it's in the C library.)
The malloc()
written for one implementation may not be work on other
implementations ?
That's right.
Also, how does malloc() determine, which pointer type has the most
strict alignment storage restrictions ? Because it has to return
a pointer that would always be aligned to the pointer type that
has most strict alignment storage restriction.

The chap who wrote the malloc knows the implementation they're
writing it for, and hence knows what the pointer alignments
are, and hence which one is the strictest.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.

[Anonymous 7843]

In article <11*********************@f14g2000cwb.googlegroups. com>,
<ju**********@yahoo.co.in> wrote:

Also, how does malloc() determine, which pointer type has the most
strict alignment storage restrictions ? Because it has to return
a pointer that would always be aligned to the pointer type that
has most strict alignment storage restriction.

Alignment is dictated by properties of the host CPU and operating
system architecture, which seldom change. Some malloc's just
have a macro or constant set to 4, 8, or 16 (for example) and
it just stays that way for decades.

A malloc meant for more portable use (like the one in the GNU C
library) probably has compile time tests or flags in the
makefile that help determine what CPU and architecture are
in play, combined with some checks on sizeof for some
basic types (long, double).

The final determination of alignment can take into
account the requested size of the item that is passed to
malloc. A request for two bytes of storage might only be
aligned on a two-byte boundary, on the valid assumption
that even though the CPU might require 4 or 8 byte alignment
in the general case, the only things that fit into a 2 byte
space (char, short) happen to require only 2 byte alignment.
--
7842++

[Lawrence Kirby]

On Tue, 21 Jun 2005 17:59:43 +0000, Anonymous 7843 wrote:

....

The final determination of alignment can take into
account the requested size of the item that is passed to
malloc. A request for two bytes of storage might only be
aligned on a two-byte boundary, on the valid assumption
that even though the CPU might require 4 or 8 byte alignment
in the general case, the only things that fit into a 2 byte
space (char, short) happen to require only 2 byte alignment.

The standard requires a non-null return from malloc() to be appropriately
aligned for any type, irrespective of the size of the allocation. It isn't
clear that a strictly conforming program could tell the difference in
every case but an implementation that doesn't stick to this rule is
treading on uncertain ground.

Lawrence

[Anonymous 7843]

In article <pa****************************@netactive.co.uk> ,
Lawrence Kirby <lk****@netactive.co.uk> wrote:

On Tue, 21 Jun 2005 17:59:43 +0000, Anonymous 7843 wrote:

...

The final determination of alignment can take into
account the requested size of the item that is passed to
malloc. A request for two bytes of storage might only be
aligned on a two-byte boundary, on the valid assumption
that even though the CPU might require 4 or 8 byte alignment
in the general case, the only things that fit into a 2 byte
space (char, short) happen to require only 2 byte alignment.

The standard requires a non-null return from malloc() to be appropriately
aligned for any type, irrespective of the size of the allocation. It isn't
clear that a strictly conforming program could tell the difference in
every case but an implementation that doesn't stick to this rule is
treading on uncertain ground.

Lawrence

A pointer-type-mismatch-signalling implementation might want to
steer clear of this trick. Can't think of anything else.
--
7842++

[Lawrence Kirby]

On Tue, 21 Jun 2005 23:24:21 +0000, Anonymous 7843 wrote:

In article <pa****************************@netactive.co.uk> ,
Lawrence Kirby <lk****@netactive.co.uk> wrote:

On Tue, 21 Jun 2005 17:59:43 +0000, Anonymous 7843 wrote:

...

The final determination of alignment can take into
account the requested size of the item that is passed to
malloc. A request for two bytes of storage might only be
aligned on a two-byte boundary, on the valid assumption
that even though the CPU might require 4 or 8 byte alignment
in the general case, the only things that fit into a 2 byte
space (char, short) happen to require only 2 byte alignment.

The standard requires a non-null return from malloc() to be appropriately
aligned for any type, irrespective of the size of the allocation. It isn't
clear that a strictly conforming program could tell the difference in
every case but an implementation that doesn't stick to this rule is
treading on uncertain ground.

Lawrence

A pointer-type-mismatch-signalling implementation might want to
steer clear of this trick. Can't think of anything else.

An issue would be something like this

char *pc = malloc(1);

if (pc != NULL)
pc = (char *)(long *)pc;

This could fail if the return value of malloc() is not appropriately
aligned for long. The question is that since it *is* required to be so
aligned whether the cast to long * and back is valid.

Lawrence

[Anonymous 7843]

In article <pa****************************@netactive.co.uk> ,
Lawrence Kirby <lk****@netactive.co.uk> wrote:

On Tue, 21 Jun 2005 23:24:21 +0000, Anonymous 7843 wrote:

In article <pa****************************@netactive.co.uk> ,
Lawrence Kirby <lk****@netactive.co.uk> wrote:

The standard requires a non-null return from malloc() to be appropriately
aligned for any type, irrespective of the size of the allocation. It isn't
clear that a strictly conforming program could tell the difference in
every case but an implementation that doesn't stick to this rule is
treading on uncertain ground.

Lawrence

A pointer-type-mismatch-signalling implementation might want to
steer clear of this trick. Can't think of anything else.

An issue would be something like this

char *pc = malloc(1);

if (pc != NULL)
pc = (char *)(long *)pc;

This could fail if the return value of malloc() is not appropriately
aligned for long. The question is that since it *is* required to be so
aligned whether the cast to long * and back is valid.

I don't see any question about it. The cast is valid C.

The implementor must be aware of whether the pointers are compatible or
not _on that implementation_ and make the choice to use the sub-aligned-
malloc trick accordingly. He may have other reasons for not using it
(i.e. it's an untested wild suggestion from some anonymous borderline
crackpot on comp.lang.c).

One subtlety is that on a lot of ostensibly pointer-alignment-sensitive
architectures (SPARC, for one) the pointers are not really checked for
alignment until dereferencing, in other words the ptr alignment stuff
is a misnomer: it would be better to call it dereference alignment or
object alignment.
--
7842++

[Peter Ammon]

Keith Thompson wrote:

ju**********@yahoo.co.in writes: [...]

Also, how does malloc() determine, which pointer type has the most
strict alignment storage restrictions ? Because it has to return
a pointer that would always be aligned to the pointer type that
has most strict alignment storage restriction.

The person who writes the malloc() function has to know enough about
the compiler to know what alignment is required.

Is the usual union alignment hack^H^H^H^Htrick not good enough?

-Peter

--
Pull out a splinter to reply.

[Keith Thompson]

Peter Ammon <ge******@splintermac.com> writes:

Keith Thompson wrote:

ju**********@yahoo.co.in writes:

[...]

Also, how does malloc() determine, which pointer type has the most
strict alignment storage restrictions ? Because it has to return
a pointer that would always be aligned to the pointer type that
has most strict alignment storage restriction.

The person who writes the malloc() function has to know enough about
the compiler to know what alignment is required.

Is the usual union alignment hack^H^H^H^Htrick not good enough?

It's not easy, and it may not even be possible, to pick a set of types
that's guaranteed to include one with the implementation's strictest
alignment.

--
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.