malloc(allocator) aligned by 8 or 16 byte

[shaanxxx]

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

[Ian Collins]

shaanxxx wrote:

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

It doesn't. It guarantees the address is suitably aligned for any type.
This has to be the case because malloc returns a void* which can be
assigned to any pointer type.

--
Ian Collins.

[Richard Heathfield]

shaanxxx said:

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

The C language standard makes no such guarantee.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

In article <11**********************@50g2000hsm.googlegroups. com>,
shaanxxx <sh******@yahoo.comwrote:

>why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

Presumably on those systems there are objects that have to be aligned
on 8- or 16- byte boundaries. For example, it's quite likely that a
double is 8 bytes long and has to be 8-byte aligned. Even if it
doesn't *have* to be aligned, it may be more efficient if it is.
This varies from system to system - you can't rely on it.

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

I can't guess what type it is on the 64-bit machine that requires
16-byte alignment.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Charlie Gordon]

"Richard Tobin" <ri*****@cogsci.ed.ac.uka écrit dans le message de news:
fc***********@pc-news.cogsci.ed.ac.uk...

In article <11**********************@50g2000hsm.googlegroups. com>,
shaanxxx <sh******@yahoo.comwrote:

>>why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

Presumably on those systems there are objects that have to be aligned
on 8- or 16- byte boundaries. For example, it's quite likely that a
double is 8 bytes long and has to be 8-byte aligned. Even if it
doesn't *have* to be aligned, it may be more efficient if it is.
This varies from system to system - you can't rely on it.

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

I can't guess what type it is on the 64-bit machine that requires
16-byte alignment.

long double could have such a requirement.
long long could be 128 bits on a 64 bit machine, and have the same
requirement.
almost anything at all can have such a requirement on a DS9K

--
Chqrlie.

[Richard Bos]

shaanxxx <sh******@yahoo.comwrote:

where i can find the current version of malloc ?

If you think that there is a real answer to that question, you are not
yet competent enough to understand the details of any implementation of
such a function.

Richard

[Flash Gordon]

shaanxxx wrote, On 13/09/07 07:55:

<snip>

where i can find the current version of malloc ?

There is NO one "current version of malloc." Each imlpementation has its
own implementation of malloc, the source of some versions are available,
others are not. Where to get it, if it is available, depends on your
implementation, so ask somewhere that talks about your implementation.
--
Flash Gordon

[Keith Thompson]

shaanxxx <sh******@yahoo.comwrites:
[...]

where i can find the current version of malloc ?

There is no such thing as "the current version of malloc".

The malloc function is specified by the C standard, as is its required
behavior. Every conforming C implementation must provide an
implementation of the malloc function; as long as it meets the
requirements, no implementation's malloc is more or less correct than
any other.

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

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <11**********************@50g2000hsm.googlegroups. com>,
shaanxxx <sh******@yahoo.comwrote:

>>why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

Presumably on those systems there are objects that have to be aligned
on 8- or 16- byte boundaries. For example, it's quite likely that a
double is 8 bytes long and has to be 8-byte aligned. Even if it
doesn't *have* to be aligned, it may be more efficient if it is.
This varies from system to system - you can't rely on it.

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

Actually the standard requires the memory to be aligned for any type
whether it's big enough or not (though if an implementation violated
this rule, it's not clear that a program could detect it).

I can't guess what type it is on the 64-bit machine that requires
16-byte alignment.

Possibly none. malloc is free to use stricter alignment than it has
to (and there might be good reasons to do so).

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

[Richard Heathfield]

Keith Thompson said:

<snip>

The malloc function is specified by the C standard, as is its required
behavior. Every conforming

hosted

C implementation must provide an implementation of the malloc
function;

<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris Dollin]

shaanxxx wrote:

I think , malloc is just wrapper on some os call (brk (unix) and
VirtualAlloc (Windows)).

Could be. (Needn't be.) It can /use/ those features without being
a wrapper round them. It doesn't /need/ to use them, either.

So chunk or memory management done by malloc
will be same for all the kind of OS.

No.

Each implementation can have /it's own/ `malloc`. There's no need
for different implementations to use the same code. There's not
even any need for the /same/ implementation to use the same code:
it could provide multiple different implementations, selected at
link-time.

please educate me how malloc algorithm will be different on different
on OS ?

/Typically/, I have read, mallocs will ask the OS [if there is one] for
/large/ chunks of memory at a time, and sub-divide those chunks as they
need for the client code [1]. How they do that sub-division is their
business. They might use a buddy system, or a Big Bag Of Pages, or a
freelist, or several freelists arranged by size. Or something.

[1] Partly because system calls can be significantly more expensive
than function calls, and because the system memory management
might not be able to do the same things as malloc/free/realloc
need to do -- like free memory between two pieces of still-
mallocated memory.

--
Chris "shh! stop barking, Malloc!" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>>Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

>>Actually the standard requires the memory to be aligned for any type
whether it's big enough or not (though if an implementation violated
this rule, it's not clear that a program could detect it).

And if you can't detect it, the standard doesn't require it.

There is at least one real consequence of the requirement. Converting
from one pointer type to another invokes UB if the resulting pointer
is not correctly aligned. So this:

long double *ptr = malloc(1);

does *not* invoke UB even if you can't store a long double in the
allocated memory.

But if the implementation doesn't impose alignment requirements on
converted pointers, but does impose alignment requirements on objects,
then an implementation can get away with having malloc(1) return a
misaligned pointer without any portable program being able to detect
it.

What I mean by the above is, for example, if a long double object must
always be aligned on an 8-byte boundary (attempting to read or write a
misaligned long double invokes UB), but all pointers are just byte
pointers, and constructing a 'long double*' that points to an odd
address doesn't do anything nasty.

[...]

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

[Flash Gordon]

Chris Dollin wrote, On 13/09/07 13:57:

shaanxxx wrote:

>I think , malloc is just wrapper on some os call (brk (unix) and
VirtualAlloc (Windows)).

Could be. (Needn't be.) It can /use/ those features without being
a wrapper round them. It doesn't /need/ to use them, either.

>So chunk or memory management done by malloc
will be same for all the kind of OS.

No.

Each implementation can have /it's own/ `malloc`. There's no need
for different implementations to use the same code. There's not
even any need for the /same/ implementation to use the same code:
it could provide multiple different implementations, selected at
link-time.

<snip>

It could even allow you to select the implementation at run time of the
application. One *very* big and well known company has even done this
with the C library for its high end OS.
--
Flash Gordon

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>There is at least one real consequence of the requirement. Converting
from one pointer type to another invokes UB if the resulting pointer
is not correctly aligned. So this:

long double *ptr = malloc(1);

does *not* invoke UB even if you can't store a long double in the
allocated memory.

True; I hadn't thought of that case.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[shaanxxx]

On Sep 14, 1:56 am, Keith Thompson <[e-mail]:

[e-mail] (Richard Tobin) writes:

In article <[e-mail]>,
Keith Thompson <[e-mail]:

>Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

>Actually the standard requires the memory to be aligned for any type
whether it's big enough or not (though if an implementation violated
this rule, it's not clear that a program could detect it).

And if you can't detect it, the standard doesn't require it.

There is at least one real consequence of the requirement. Converting
from one pointer type to another invokes UB if the resulting pointer
is not correctly aligned. So this:

long double *ptr = malloc(1);

does *not* invoke UB even if you can't store a long double in the
allocated memory.

But if the implementation doesn't impose alignment requirements on
converted pointers, but does impose alignment requirements on objects,
then an implementation can get away with having malloc(1) return a
misaligned pointer without any portable program being able to detect
it.

What I mean by the above is, for example, if a long double object must
always be aligned on an 8-byte boundary (attempting to read or write a
misaligned long double invokes UB), but all pointers are just byte
pointers, and constructing a 'long double*' that points to an odd
address doesn't do anything nasty.

[...]

--
Keith Thompson (The_Other_Keith) [e-mail] <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"

sorry I am not good at short forms , what is UB ?

[Richard Heathfield]

shaanxxx said:

<snip>

sorry I am not good at short forms , what is UB ?

He means "undefined behaviour", i.e. behaviour on which the Standard
imposes no constraints.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999