Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > malloc and realloc

Reply
Thread Tools

malloc and realloc

 
 
ravi.cs.2001@gmail.com
Guest
Posts: n/a
 
      01-27-2007
Hi all,

I m relatively new to C. I have few queries related to malloc():

#1. When we perform malloc(), the memory allocated dynamically comes
from the heap area of the process in concern. Well, we then say that
the heap has shrinked. my query is: Is it that the heap physically
does not shrink but the perticular nodes are marked 'ALLOCATED' and
for subsequent calls to malloc() the memory manager remembers them and
does not reference them?

#2. With realloc(), if some pointer 'ptr' is pointing initially to a
perticular position in a buffer (char *buffer) then on performing a
realloc() on this buffer, what will be 'ptr' pointing to?

#3. whats the maximum memory size that we can allocate dynamically by
calling malloc() ?

thanx in advance

Ravs

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      01-27-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) said:

> Hi all,
>
> I m relatively new to C. I have few queries related to malloc():
>
> #1. When we perform malloc(), the memory allocated dynamically comes
> from the heap area of the process in concern.


The Standard doesn't guarantee that. In C terms, the memory is allocated
from the free store, wherever that may be.

> Well, we then say that
> the heap has shrinked. my query is: Is it that the heap physically
> does not shrink but the perticular nodes are marked 'ALLOCATED' and
> for subsequent calls to malloc() the memory manager remembers them and
> does not reference them?


This is entirely up to the implementation.

>
> #2. With realloc(), if some pointer 'ptr' is pointing initially to a
> perticular position in a buffer (char *buffer) then on performing a
> realloc() on this buffer, what will be 'ptr' pointing to?


If realloc succeeds, the value should be treated as indeterminate. The
proper way to use realloc is:

tmp = realloc(ptr, newsize);
if(tmp != NULL)
{
ptr = tmp; /* old pointer value should be considered dead, as your
buffer may have moved. */
}
else
{
allocation failed, but at least you still have your old buffer intact
}

>
> #3. whats the maximum memory size that we can allocate dynamically by
> calling malloc() ?


The absolute limit for any one call is (size_t)-1 bytes - i.e. the largest
value that can be stored in a size_t, because that's the largest value you
can pass to malloc. But you should not be surprised if implementations do
not allow you to allocate this much. ALWAYS check the result of malloc to
determine whether the call succeeded before trying to use the space you
requested.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      01-27-2007
(E-Mail Removed) wrote:
>
> I m relatively new to C. I have few queries related to malloc():
>
> #1. When we perform malloc(), the memory allocated dynamically comes
> from the heap area of the process in concern. Well, we then say that
> the heap has shrinked. my query is: Is it that the heap physically
> does not shrink but the perticular nodes are marked 'ALLOCATED' and
> for subsequent calls to malloc() the memory manager remembers them and
> does not reference them?


More or less. The actual mechanism is up to the system involved.
There is no reason a 'heap' has to exist. The system could be
implemented with small boys writing data on a slate. It might be
slow, but there is no speed specification.

>
> #2. With realloc(), if some pointer 'ptr' is pointing initially to a
> perticular position in a buffer (char *buffer) then on performing a
> realloc() on this buffer, what will be 'ptr' pointing to?


If the pointer is anything other than the value originally returned
by malloc, calloc, or realloc the action is undefined. You could
set off WWIII.

>
> #3. whats the maximum memory size that we can allocate dynamically by
> calling malloc() ?


No such. The only indication you have is the failure of
malloc/calloc/realloc by returning NULL. After which you decide
what to do.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews


 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      01-27-2007
(E-Mail Removed) wrote:
> Hi all,
>
> I m relatively new to C. I have few queries related to malloc():
>
> #1. When we perform malloc(), the memory allocated dynamically comes
> from the heap area of the process in concern. Well, we then say that
> the heap has shrinked. my query is: Is it that the heap physically
> does not shrink but the perticular nodes are marked 'ALLOCATED' and
> for subsequent calls to malloc() the memory manager remembers them and
> does not reference them?


C doesn't talk about heaps. As far as a portable C program is
concerned, the *alloc() functions are to be treated as a black box.
They either succeed or fail. The details of their internal operation
are not specified by the C standard. Different systems may use
different strategies, even varying from call to call. In a portable
program, the calling code need not bother about such things.

> #2. With realloc(), if some pointer 'ptr' is pointing initially to a
> perticular position in a buffer (char *buffer) then on performing a
> realloc() on this buffer, what will be 'ptr' pointing to?


realloc() may physically move the block during resizing, so any
pointers to the block become invalidated after a successful call to
malloc(). They'll need to be updated. Note though that if realloc()
fails, the original memory is left untouched and remains valid to use.

> #3. whats the maximum memory size that we can allocate dynamically by
> calling malloc() ?


Since malloc() takes a parameter of type size_t, the absolute largest
value you can pass to it, without causing wrap-around, is SIZE_MAX
bytes, defined in stddef.h.

 
Reply With Quote
 
Serve Laurijssen
Guest
Posts: n/a
 
      01-27-2007

"CBFalconer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (E-Mail Removed) wrote:
>>
>> I m relatively new to C. I have few queries related to malloc():
>>
>> #1. When we perform malloc(), the memory allocated dynamically comes
>> from the heap area of the process in concern. Well, we then say that
>> the heap has shrinked. my query is: Is it that the heap physically
>> does not shrink but the perticular nodes are marked 'ALLOCATED' and
>> for subsequent calls to malloc() the memory manager remembers them and
>> does not reference them?

>
> More or less. The actual mechanism is up to the system involved.
> There is no reason a 'heap' has to exist. The system could be
> implemented with small boys writing data on a slate. It might be
> slow, but there is no speed specification.


I really really wanna see a platform like that. And when the boys have
weekend malloc returns NULL I take it?


 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      01-27-2007
santosh wrote:
<snip>

> realloc() may physically move the block during resizing, so any
> pointers to the block become invalidated after a successful call to
> malloc().


That should read:
[ ... ] after a successful call to realloc().

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      01-27-2007
Serve Laurijssen wrote:
> "CBFalconer" <(E-Mail Removed)> wrote in message
>> (E-Mail Removed) wrote:
>>>
>>> I m relatively new to C. I have few queries related to malloc():
>>>
>>> #1. When we perform malloc(), the memory allocated dynamically comes
>>> from the heap area of the process in concern. Well, we then say that
>>> the heap has shrinked. my query is: Is it that the heap physically
>>> does not shrink but the perticular nodes are marked 'ALLOCATED' and
>>> for subsequent calls to malloc() the memory manager remembers them and
>>> does not reference them?

>>
>> More or less. The actual mechanism is up to the system involved.
>> There is no reason a 'heap' has to exist. The system could be
>> implemented with small boys writing data on a slate. It might be
>> slow, but there is no speed specification.

>
> I really really wanna see a platform like that. And when the boys
> have weekend malloc returns NULL I take it?


No, the malloc call just doesn't return until Monday NULL is
for when all the boys slates are in use. BTW, a pointer here
resolves to a boys name, and cannot meaningfully be converted
to/from an int.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews


 
Reply With Quote
 
David T. Ashley
Guest
Posts: n/a
 
      01-27-2007
"Serve Laurijssen" <(E-Mail Removed)> wrote in message
news:epfuao$pid$(E-Mail Removed)1.ov.home.nl...
>
> "CBFalconer" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> (E-Mail Removed) wrote:
>>>
>>> I m relatively new to C. I have few queries related to malloc():
>>>
>>> #1. When we perform malloc(), the memory allocated dynamically comes
>>> from the heap area of the process in concern. Well, we then say that
>>> the heap has shrinked. my query is: Is it that the heap physically
>>> does not shrink but the perticular nodes are marked 'ALLOCATED' and
>>> for subsequent calls to malloc() the memory manager remembers them and
>>> does not reference them?

>>
>> More or less. The actual mechanism is up to the system involved.
>> There is no reason a 'heap' has to exist. The system could be
>> implemented with small boys writing data on a slate. It might be
>> slow, but there is no speed specification.

>
> I really really wanna see a platform like that. And when the boys have
> weekend malloc returns NULL I take it?


No. Such systems also maintain a large collection of trained rats. When
the boys have weekend, the trained rats do the same job. As part of the
weekend activities, the boys have to bring back food and treats for the
trained rats.

In fact, this is the way my *nix box actually works internally. The system
documentation makes reference to CPU, silicon wafer, etc., but I know
better.

--
David T. Ashley ((E-Mail Removed))
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)


 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-27-2007

"Richard Heathfield" <(E-Mail Removed)> wrote in message
> The absolute limit for any one call is (size_t)-1 bytes - i.e. the largest
> value that can be stored in a size_t, because that's the largest value you
> can pass to malloc. But you should not be surprised if implementations do
> not allow you to allocate this much. ALWAYS check the result of malloc to
> determine whether the call succeeded before trying to use the space you
> requested.
>

Actually Windows guarantees that allocations of under 8K or something like
that will succeed, unless the program is responding to a request to shut
down due to lack of memory, in which case 64K of allocation or so is
guaranteed, but not an infinite supply of 64K chunks.

So on a modern operating system you don't need to check small mallocs. You
do if code is to be completley portable, of course.


 
Reply With Quote
 
matevzb
Guest
Posts: n/a
 
      01-27-2007
On Jan 27, 9:16 pm, "Malcolm McLean" <(E-Mail Removed)> wrote:
> "Richard Heathfield" <(E-Mail Removed)> wrote in message
> > The absolute limit for any one call is (size_t)-1 bytes - i.e. the largest
> > value that can be stored in a size_t, because that's the largest value you
> > can pass to malloc. But you should not be surprised if implementations do
> > not allow you to allocate this much. ALWAYS check the result of malloc to
> > determine whether the call succeeded before trying to use the space you
> > requested.

> Actually Windows guarantees that allocations of under 8K or something like
> that will succeed, unless the program is responding to a request to shut
> down due to lack of memory, in which case 64K of allocation or so is
> guaranteed, but not an infinite supply of 64K chunks.

I'll have to ask for chapter&verse on this one. If you're referring to
Windows malloc(), the manual explicitly states "Always check the
return from malloc, even if the amount of memory requested is small".
Furthermore, malloc() uses HeapAlloc() to get the memory: "Memory
allocated by HeapAlloc is not movable. Because the memory is not
movable, the heap can become fragmented". In theory, it could become
so fragmented, that you wouldn't be able to get 8K.
> So on a modern operating system you don't need to check small mallocs. You
> do if code is to be completley portable, of course.

The conclusion is drawn from Windows, can you be sure this should
apply to all other systems as well?
--
WYCIWYG - what you C is what you get

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Different sizes of data and function pointers on a machine -- void*return type of malloc, calloc, and realloc Myth__Buster C Programming 23 06-26-2012 08:29 PM
A Question about new vs malloc and realloc. DrBob C++ 2 11-26-2003 10:17 PM
Problem with malloc, realloc, _msize and memcpy Bren C++ 8 09-03-2003 11:01 PM
Re: Override malloc,calloc,realloc and free? Dan Pop C Programming 0 06-26-2003 04:52 PM
Re: Override malloc,calloc,realloc and free? Jun Woong C Programming 0 06-26-2003 03:49 PM



Advertisments