Discussion:
Regarding malloc memory alignment
(too old to reply)
r***@gmail.com
2007-12-06 16:50:09 UTC
Permalink
Hi Group,

I have one question.

If I am allocating memory of 38 bytes to an integer pointer, what will
be the memory actually allocated?

Will there be any memory alignment concept in malloc?

Please let me know the reasons if it is yes / no.

Regards
Ram.
Ben Pfaff
2007-12-06 17:03:13 UTC
Permalink
Post by r***@gmail.com
I have one question.
It looks like two questions to me.
Post by r***@gmail.com
If I am allocating memory of 38 bytes to an integer pointer, what will
be the memory actually allocated?
If you call malloc(38), you will get at least 38 bytes of memory
and possibly more (or no bytes of memory, if the request cannot
be satisfied). How much more depends on your implementation and
possibly on the preexisting state of the system.
Post by r***@gmail.com
Will there be any memory alignment concept in malloc?
Memory allocated with malloc is suitably aligned for any standard
C purpose. The C standard says this explicitly:

The pointer returned if the allocation succeeds is suitably
aligned so that it may be assigned to a pointer to any type
of object and then used to access such an object or an array
of such objects in the space allocated (until the space is
explicitly deallocated).
--
"If I've told you once, I've told you LLONG_MAX times not to
exaggerate."
--Jack Klein
Joachim Schmitz
2007-12-06 17:03:24 UTC
Permalink
Post by r***@gmail.com
Hi Group,
I have one question.
If I am allocating memory of 38 bytes to an integer pointer, what will
be the memory actually allocated?
malloc will give you at least as many bytes as you asked it for or none at
all.
Post by r***@gmail.com
Will there be any memory alignment concept in malloc?
The memory you got will be properly aligned for whatever purpose you may
want to use it for.
Post by r***@gmail.com
Please let me know the reasons if it is yes / no.
Because the standard say so.
Post by r***@gmail.com
Regards
Ram.
Bye, Jojo
Chris Dollin
2007-12-07 10:34:02 UTC
Permalink
Post by r***@gmail.com
If I am allocating memory of 38 bytes to an integer pointer, what will
be the memory actually allocated?
You mean if you write

int *malloced = malloc( 38 );

in a function (with all suitable #includes and whatever)?

You will get a pointer to 38 bytes of (uninitialised) memory [1]. What this
means is that those 38 bytes can be written to and (then) read from,
but that trying to access bytes after (or before) those 38 gets you
undefined behaviour, as does computing the address of any bytes outside
the 38 (+1 for the Special Exception) [2].

I note that if sizeof(int) doesn't exactly divide 38, and you really wanted
to use the memory for ints, you'll have some useless bytes hanging around
at the end.
Post by r***@gmail.com
Will there be any memory alignment concept in malloc?
The Standard requires that the memory returned by malloc is suitably aligned
for any C data-type. How the implementation achieves this is left to it
(but each implementation of course knows what the alignment requirements
of its data-types are, so it's not hard to do, just not portable).

[1] Or null.

[2] The implementation of undefined behaviour need not /do/ anthing; it
could quite cheerfully read from random other variables (Bad) or
write to them (Very Extremely Horribly RunAway! Bad).
--
Chris "running is for the jetpackless" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
r***@gmail.com
2007-12-07 17:10:33 UTC
Permalink
Post by Chris Dollin
Post by r***@gmail.com
If I am allocating memory of 38 bytes to an integer pointer, what will
be the memory actually allocated?
You mean if you write
int *malloced = malloc( 38 );
in a function (with all suitable #includes and whatever)?
You will get a pointer to 38 bytes of (uninitialised) memory [1]. What this
means is that those 38 bytes can be written to and (then) read from,
but that trying to access bytes after (or before) those 38 gets you
undefined behaviour, as does computing the address of any bytes outside
the 38 (+1 for the Special Exception) [2].
I note that if sizeof(int) doesn't exactly divide 38, and you really wanted
to use the memory for ints, you'll have some useless bytes hanging around
at the end.
Post by r***@gmail.com
Will there be any memory alignment concept in malloc?
The Standard requires that the memory returned by malloc is suitably aligned
for any C data-type. How the implementation achieves this is left to it
(but each implementation of course knows what the alignment requirements
of its data-types are, so it's not hard to do, just not portable).
[1] Or null.
[2] The implementation of undefined behaviour need not /do/ anthing; it
could quite cheerfully read from random other variables (Bad) or
write to them (Very Extremely Horribly RunAway! Bad).
--
Chris "running is for the jetpackless" Dollin
registered office: Berks RG12 1HN 690597 England
Hi All,

Thank you very much for your replies. But still I am confused how it
will align if I allocate 38 bytes because malloc never allocates more
memory for alignment.

Is this point right? - PLease correct me if I am wrong.

According to standard, if alignment is done, how can we make sure
that ?

Can you please show me with an example?

Thanks in advance,

Regards
Ram.
Richard Heathfield
2007-12-07 17:16:47 UTC
Permalink
***@gmail.com said:

<snip>
Post by r***@gmail.com
But still I am confused how it
will align if I allocate 38 bytes because malloc never allocates more
memory for alignment.
The Standard offers no such guarantee.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
J. J. Farrell
2007-12-07 22:01:07 UTC
Permalink
Post by r***@gmail.com
Post by Chris Dollin
Post by r***@gmail.com
If I am allocating memory of 38 bytes to an integer pointer, what will
be the memory actually allocated?
You mean if you write
int *malloced = malloc( 38 );
in a function (with all suitable #includes and whatever)?
You will get a pointer to 38 bytes of (uninitialised) memory [1]. What this
means is that those 38 bytes can be written to and (then) read from,
but that trying to access bytes after (or before) those 38 gets you
undefined behaviour, as does computing the address of any bytes outside
the 38 (+1 for the Special Exception) [2].
I note that if sizeof(int) doesn't exactly divide 38, and you really wanted
to use the memory for ints, you'll have some useless bytes hanging around
at the end.
Post by r***@gmail.com
Will there be any memory alignment concept in malloc?
The Standard requires that the memory returned by malloc is suitably aligned
for any C data-type. How the implementation achieves this is left to it
(but each implementation of course knows what the alignment requirements
of its data-types are, so it's not hard to do, just not portable).
[1] Or null.
[2] The implementation of undefined behaviour need not /do/ anthing; it
could quite cheerfully read from random other variables (Bad) or
write to them (Very Extremely Horribly RunAway! Bad).
Thank you very much for your replies. But still I am confused how it
will align if I allocate 38 bytes because malloc never allocates more
memory for alignment.
Is this point right? - PLease correct me if I am wrong.
What do you mean by your "because" statement? There's no saying how much
memory malloc will use up in order to satisfy your request for 38 bytes.
It could take a megabyte of memory and return you a pointer to somewhere
in the middle of that if it chose. That would be a very strange and
inefficient implementation, but it would be valid. If a call to malloc
succeeds, you know that you can make use of the number of bytes you
asked for, and that the address you were given is aligned suitably for
any use - you can convert it to any kind of data pointer and use it
(assuming the size you allocated is appropriate for the use).
Post by r***@gmail.com
According to standard, if alignment is done, how can we make sure
that ?
I don't understand what you mean.
Post by r***@gmail.com
Can you please show me with an example?
I don't know what you want an example of.
Gordon Burditt
2007-12-07 23:55:12 UTC
Permalink
Post by r***@gmail.com
Thank you very much for your replies. But still I am confused how it
will align if I allocate 38 bytes because malloc never allocates more
memory for alignment.
malloc() never allocates *LESS* than the memory you requested (unless
it returns NULL, in which case it allocates nothing). Beyond that,
it is Not Your Problem (tm) and You Have No Stanard Way Of Checking
That So Don't Try(tm).
Post by r***@gmail.com
Is this point right? - PLease correct me if I am wrong.
No.

malloc() probably also allocates something (memory, disk space,
cash) to keep track of your allocation, even if there is no alignment
issue. It may allocate that as disk space in a SQL server in a
Microsoft Dungeon in Redmond. Or maybe in RAM near the memory it
gave you.
Post by r***@gmail.com
According to standard, if alignment is done, how can we make sure
that ?
According to the standard, you are NOT ALLOWED TO TRY TO CHECK THIS.
Post by r***@gmail.com
Can you please show me with an example?
I don't see the point in showing an example of NOT attempting to
check alignment of a pointer returned from malloc().
Chris Dollin
2007-12-08 01:14:56 UTC
Permalink
Post by r***@gmail.com
Thank you very much for your replies. But still I am confused how it
will align if I allocate 38 bytes because malloc never allocates more
memory for alignment.
You don't know that -- and it isn't true.
Post by r***@gmail.com
According to standard, if alignment is done, how can we make sure
that ?
We can't, not portably, which is why malloc is required to do it.

What actual problem are you trying to solve?
--
Concrete Is Better Than Tracts Hedgehog
"I just wonder when we're going to have to sit down and re-evaluate
our decision-making paradigm." /Sahara/
CBFalconer
2007-12-08 00:14:54 UTC
Permalink
Post by r***@gmail.com
Post by Chris Dollin
Post by r***@gmail.com
If I am allocating memory of 38 bytes to an integer pointer,
what will be the memory actually allocated?
You mean if you write
int *malloced = malloc( 38 );
in a function (with all suitable #includes and whatever)?
You will get a pointer to 38 bytes of (uninitialised) memory [1].
What this means is that those 38 bytes can be written to and
(then) read from, but that trying to access bytes after (or
before) those 38 gets you undefined behaviour, as does computing
the address of any bytes outside the 38 (+1 for the Special
Exception) [2].
I note that if sizeof(int) doesn't exactly divide 38, and you
really wanted to use the memory for ints, you'll have some
useless bytes hanging around at the end.
Post by r***@gmail.com
Will there be any memory alignment concept in malloc?
The Standard requires that the memory returned by malloc is
suitably aligned for any C data-type. How the implementation
achieves this is left to it (but each implementation of course
knows what the alignment requirements of its data-types are, so
it's not hard to do, just not portable).
[1] Or null.
[2] The implementation of undefined behaviour need not /do/
anthing; it could quite cheerfully read from random other
variables (Bad) or write to them (Very Extremely Horribly
RunAway! Bad).
Thank you very much for your replies. But still I am confused
how it will align if I allocate 38 bytes because malloc never
allocates more memory for alignment.
Chris has summarized what the standard guarantees. Why and how is
not discussable, because malloc is necessarily a system dependant
function. It cannot be written in portable C, although you can get
fairly close. So your remaining questions can only be dealt with
for a specific implementation, and are thus off topic here on
c.l.c. What can be discussed here is how best to use it.

You can examine one implementation (if you like) at:

<http://cbfalconer.home.att.net/download/nmalloc.zip>
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Loading...