Regarding malloc memory alignment

[ramsatishv]

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]

I have one question.

It looks like two questions to me.

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.

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

 

[Joachim Schmitz]

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.

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.

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

Because the standard say so.

Regards
Ram.

Bye, Jojo

 

[Chris Dollin]

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.

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

 

[ramsatishv]

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.

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

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]

(e-mail address removed) said:

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.

 

[J. J. Farrell]

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.

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

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

I don't understand what you mean.

Can you please show me with an example?

I don't know what you want an example of.

 

[Gordon Burditt]

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

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.

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.

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

 

[CBFalconer]

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.

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>

 

[Chris Dollin]

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.

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?

 

[schat]

If you are using 32 bit architecture and you use malloc(38) then the result is unpredictable. However the following scenario might occur:
38 Bytes of memory + 2 Bytes of padding will be allocated to overcome the memory alignment issues. You will be able to use the 2 Bytes of padding for your purposes which again depends on the implementation. So effectively you will get 40 Bytes of memory where you can store 10 Integer values.

But please keep in mind that whatever I have mentioned above is one of the many possibilities and that is why we say that the outcome is unpredictable.
To make sure that memory alignment issues do not arise we allocate memory as: malloc(n_elem * sizeof(DataType)
Eg. int *ptr = (int *)malloc(10 * sizeof(int));


Hope this helped.