malloc realloc and pointers

R

ravi

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

4. Is it valid in C to typecast a pointer? eg. code snippet... of
course int is 16 bit and long is 32 bit.
int *variable, value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;

thanx in advance
 
P

Peter Nilsson

ravi said:
Hi all,

I m relatively new to C.

Then why ask questions on how it's implemented? You're
trying to run before you can crawl.
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.

If you say so. The language standard does not specify how
malloc is implemented, merely how it must operate.
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?

You should ask in a group where such implementation details
are topical.
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?

The original pointer value becomes indeterminate if the
allocation is successful.
3. whats the maximum memory size that we can allocate
dynamically by calling malloc() ?

The most you can try for is ((size_t) -1). The most you
can actually allocate depends on the implementation.
4. Is it valid in C to typecast a pointer?

Yes, but subject to a few rules. Converting between
different non-void types isn't as well defined as
some program code would have you believe.
eg. code snippet... of
course int is 16 bit and long is 32 bit.

If that has any relevance, then you're heading down the
wrong path in your quest to learn C.
int *variable, value;
*((long*)variable)++ = value;

This potentially breaks several rules on pointer conversion.
It also violates a constraint.

The cast from int * to long * is not required to be well
defined. Even if it is, it will not produce a modifiable
lvalue suitable for postfix ++.
 
K

Kenneth Brody

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

Technically, C doesn't define "heap". However, it is a term in
general use to mean "the memory from which malloc and friends
get their memory".
Well, we then say that the heap
has shrinked.

Not necessarily. Perhaps the amount of memory available on the
heap has shrunk, but even that's not necessarily true. It is
possible that the memory you request wasn't available in the
existing heap, and so the heap was grown to accomodate your
request. It is possible that the result is that you now have
more memory available on the heap than before the call to
malloc().
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?

The memory management within malloc/calloc/etc. keeps track of
what memory is used and that is still available. The details on
How it does this is entirely up to the implemenation.
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?

Three possibilities:

1) realloc() returns the same pointer, in which case ptr is still
valid, pointing to the newly-sized buffer.

2) realloc() returns a different pointer, in which case ptr is
no longer valid, and must not be dereferenced.

3) realloc() returns NULL, in which case ptr is pointing to the
unchanged memory region as before.

Typically, the only use for the old pointer is to remember where
it pointed to when realloc() returns NULL. Otherwise, simply use
the new pointer.
3. whats the maximum memory size that we can allocate dynamically by
calling malloc() ?

Whatever is the maximum value of a size_t variable, though you
are more likely to run into limits of the platform you are running
on. (For example, size_t may allow values up to 4GB-1, but the
O/S may only allow 2GB.)
4. Is it valid in C to typecast a pointer? eg. code snippet... of
course int is 16 bit and long is 32 bit.
int *variable, value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;

If variable is properly aligned, I believe it's valid.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
H

Harald van Dijk

Three possibilities:

1) realloc() returns the same pointer, in which case ptr is still
valid, pointing to the newly-sized buffer.

According to DR #260, applied to realloc, even if memcmp proves the new
pointer is identical to the old pointer, you're not allowed to use them
interchangeably. If you pass a non-null pointer ptr to realloc, and it
doesn't return a null pointer, ptr is no longer valid.

(I do not believe the DR's conclusions can be drawn from any
interpretation of the actual standard, and in fact I believe some points
from the DR directly contradict explicit guarantees by the standard, but
that's just me.)
 
C

CBFalconer

ravi said:
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?

There is not necessarily anything called a heap. That is an
implementors decision. Somehow or other the implementor guarantees
that subsequent malloc calls do not return pointers to previously
allocated space (unless freed).
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?

That depends. If realloc succeeds, it returns a replacement value
for ptr, which has the desired space and preserves the original
data. If realloc fails it return NULL, and ptr and *ptr are both
unaltered.
3. whats the maximum memory size that we can allocate dynamically by
calling malloc() ?

Depends on the system. All you can find out is that a malloc
(etc.) request is fulfilled or rejected.
4. Is it valid in C to typecast a pointer? eg. code snippet... of
course int is 16 bit and long is 32 bit.
int *variable, value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;

Very likely to cause serious run-time faults. Don't do it.
 
J

Jack Klein

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

4. Is it valid in C to typecast a pointer? eg. code snippet... of
course int is 16 bit and long is 32 bit.
int *variable, value;
*((long*)variable)++ = value;

This is not legal C code. The cast generates an rvalue, and the post
increment operator cannot be applied to lvalues. You cannot assign to
the result of a cast.
*((long*)variable)++ = value;
*((long*)variable)++ = value;
*((long*)variable)++ = value;

thanx in advance

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
K

K. Jennings

Three possibilities:

1) realloc() returns the same pointer, in which case ptr is still
valid, pointing to the newly-sized buffer.

2) realloc() returns a different pointer, in which case ptr is
no longer valid, and must not be dereferenced.

3) realloc() returns NULL, in which case ptr is pointing to the
unchanged memory region as before.

What happens when ptr is not one returned by a previous
invocation to malloc(), calloc() or realloc()?
 
C

cr88192

K. Jennings said:
What happens when ptr is not one returned by a previous
invocation to malloc(), calloc() or realloc()?

then, if you are the program, ninjas run up, kick you somewhere painful, and
insert a corncob somewhere painful.
one then has to try to hobble off to the bathroom for a 'core dump'...
 
C

CBFalconer

K. Jennings said:
.... snip ...

What happens when ptr is not one returned by a previous
invocation to malloc(), calloc() or realloc()?

Then you know that realloc moved the storage. It doesn't affect
the data held by the pointed to object.
 
K

Keith Thompson

K. Jennings said:
[snip]
What happens when ptr is not one returned by a previous
invocation to malloc(), calloc() or realloc()?

Undefined behavior.

(This is partly a test of news-server.san.rr.com.)
 
N

Nick Keighley

Then why ask questions on how it's implemented? You're
trying to run before you can crawl.

in theory this is the right answer but some people need
a concrete implementation to hang their thoughts on.

E1: "but you don't need to know the dtails of how that works!"
E2: "yes I do!"
E1: "you wouldn't expect to know the dtails of how the compiler
worked would you?"
E2: "well yes I would actually"


"I understood once I realised it's all shift registers!"
an explanation of the functioning of a digital switch,
that I felt lacked detail.


If you say so. The language standard does not specify how
malloc is implemented, merely how it must operate.

again, an outline sketch of an implementation can help.


typically, yes (actually pretty well certainly, yes!)

<snip>
 
F

Flash Gordon

CBFalconer wrote, On 30/11/07 00:42:
ravi wrote:


Depends on the system. All you can find out is that a malloc
(etc.) request is fulfilled or rejected.

<snip>

You also know that you cannot allocate more than (size_t)-1 bytes with a
single call to malloc.
 
C

cr88192

Nick Keighley said:
in theory this is the right answer but some people need
a concrete implementation to hang their thoughts on.

yes.

in the college where I am going, this has sometimes been referred to as a
difference between platonic and aristotelean thought processes...

E1: "but you don't need to know the dtails of how that works!"
E2: "yes I do!"
E1: "you wouldn't expect to know the dtails of how the compiler
worked would you?"
E2: "well yes I would actually"


"I understood once I realised it's all shift registers!"
an explanation of the functioning of a digital switch,
that I felt lacked detail.

I originally partly learned C by examining lots of assembler output from the
compiler (at first I had found assembler easier to understand).

so, this was my early years:
I started with basic, later moving to assembler.
I then more or less moved from assembler to C.

back in my early days of learning C, there were more than a few things that
I learned from the wolfenstien source as well...

look at source, try to figure out how to imitate it...


then I moved to 32 bit archs, as over the years 16-bit was gradually
replaced by 32-bit, and dos by windows and linux. for a long time after
this, I continued on with a faulty understanding of all that was going on in
assembler land, until more recently when I have gotten much more heavily
involved with assembler again (compiler writing does this...).

and, now, for me much of a lifetime later, we are again seeing a transition,
from 32 to 64 bits...


and I watch as those of us born in the 80s are becomming 'old', being
rapidly replaced by those from the 90s...
a few years back, people born in the 80s were still young, and people born
in the 90s were little kids...

time passes and the distant past becomes ever more detached, as my life
quickly escaped me and I become old and pointless, in a life quickly going
nowhere...

and such...
 
C

CBFalconer

cr88192 said:
.... snip ...

and I watch as those of us born in the 80s are becomming 'old',
being rapidly replaced by those from the 90s... a few years back,
people born in the 80s were still young, and people born in the
90s were little kids...

time passes and the distant past becomes ever more detached, as
my life quickly escaped me and I become old and pointless, in a
life quickly going nowhere...

Now try the effect of being born in the early '30s. :)
 
S

santosh

cr88192 wrote:

I originally partly learned C by examining lots of assembler output
from the compiler (at first I had found assembler easier to
understand).

so, this was my early years:
I started with basic, later moving to assembler.
I then more or less moved from assembler to C.

It was a slightly different sequence for me. My first languages were
BASIC (BASICA) and Pascal. Then I moved on to C and now more recently,
I have also been dabbling in assembler (x86_32).

I also know a fair bit of Java, Perl and shell (sh).

I prefer C or assembler for hobby programming. To hack out a quick
prototype I usually use Perl or bash. Of course BASIC and Pascal have
fallen by the wayside...
back in my early days of learning C, there were more than a few things
that I learned from the wolfenstien source as well...

My approach is a bit different. I read up on a concept and then try my
hand at several "demos" that exercise that. For a long time before
finding this group I did not really pay any attention to portability -
my code used to make heavy use of compiler extensions. Now of course, I
try to keep as much of my code as possible portable.
look at source, try to figure out how to imitate it...

This approach has generally not worked that well for me. I prefer the
textbook and try-it-and-see approach. But to each his own I guess.

and, now, for me much of a lifetime later, we are again seeing a
transition, from 32 to 64 bits...

Yes. For the moment I'm still staying with x86_32. The prospect of
learning yet another bunch of instructions and rules is wearysome, but
sooner rather than later I'll have to crack open the x86_64 manuals.
Sometimes I wish Herbert's 68000 series had made it instead of Intel's
IA-32. It'd have so much easier on the grey matter...

<snip>
 
C

cr88192

santosh said:
cr88192 wrote:



It was a slightly different sequence for me. My first languages were
BASIC (BASICA) and Pascal. Then I moved on to C and now more recently,
I have also been dabbling in assembler (x86_32).

yeah.
I started out with QBasic...

but, in time one runs into some limitations with basic, and assembler was in
part an escape.
I started learning C as well, but it was an indirect path.

all this was starting partyway through elem (I think mostly starting around
3rd and 4th grade), where I started transitioning to messing with C and
transitioning mostly to assembler sometime around 6th grade.

by 8th grade, I was writing stuff almost purely in C.

I didn't really start making "progress" on things until about the middle or
end of highschool, with the first noteworthy project being a crude OS
(32-bit protected mode, ...). eventually this project died for looking too
much like "yet another unix" (but horribly buggy with lacking driver
support).

and, time has moved on...

many years have gone by since then (ok, it is still a "one hand" number, but
I still feel old and useless...). everything seems so long ago, my life
quickly escaping from me...


by now I should have been presumably independent, with a job and female
interest and so on...
but, it is lame, I am still stuck going to college and females are not
interested in someone like me...
they seemingly all find someone already, yet I am still alone...

I also know a fair bit of Java, Perl and shell (sh).

never really learned Java in much detail (I learned enough to give me a
strong distaste for OO for a number of years).

Perl, never really liked or felt much need for.
'sh', too minor of a thing to really consider much of.

I prefer C or assembler for hobby programming. To hack out a quick
prototype I usually use Perl or bash. Of course BASIC and Pascal have
fallen by the wayside...

yes. I haven't done much of anything in basic for many years.

My approach is a bit different. I read up on a concept and then try my
hand at several "demos" that exercise that. For a long time before
finding this group I did not really pay any attention to portability -
my code used to make heavy use of compiler extensions. Now of course, I
try to keep as much of my code as possible portable.

I primarily learned things by studying and immitating things.
so, it was wolfenstien, doom, quake, and the linux kernel, mostly...

moving past that, I switched primarily to independent projects...

This approach has generally not worked that well for me. I prefer the
textbook and try-it-and-see approach. But to each his own I guess.

books are hard to come by.
parents never really much liked buying books for me (or, at least, ones that
were actually useful).

they were good at getting total introductory/newb books, but I don't really
need books with a bunch of stuff I already know.

Yes. For the moment I'm still staying with x86_32. The prospect of
learning yet another bunch of instructions and rules is wearysome, but
sooner rather than later I'll have to crack open the x86_64 manuals.
Sometimes I wish Herbert's 68000 series had made it instead of Intel's
IA-32. It'd have so much easier on the grey matter...

yes, ok.

well, 16-bits was fading when I was back in elem, watching the change in
progress, as the distant past transitions into the present.

I remember when I was back in HS or so and heard about x86-64 (I was like,
cool, a 64 bit chip that there is actually reason to use...), but it took so
long in comming out, me getting one, and am still waiting for good OS
support, ...


so, the world has changed some since when I was young...
slowly but surely the world has changed.
 
C

cr88192

CBFalconer said:
Now try the effect of being born in the early '30s. :)

your case, or hypothetical?...


I guess the changes for someone who has lived so long would be far greater
than what I have seen in my 2+ decades of existence (of which I can remember
maybe about 12-15 years of it, and of which I have been coding most of
this...).

well, it will soon be my birthday.
another year older, and I have little to show for it...
well, I wrote a C compiler this year, and wrote a few other things, maybe at
least worth something...

but, in time, my life will end, and I wonder if I will ever have much of
anything to show for having existed.
what of all the people younger than me possible making more impressive
achievements?...
one gets overrun and one gets replaced...

like middle or high schoolers or such who can pull off maybe 200 or 300
kloc/year or more?...
maybe they can write impressive stuff, or make interesting discoveries?...

it has been much of a year, and my compiler has not even broken 100 kloc
yet.

taking my average rate calculated earlier this year, and estimating for a
full year, it comes out to about 100kloc/year, which is probably rather
lame...
 
S

santosh

cr88192 said:
your case, or hypothetical?...

but, in time, my life will end, and I wonder if I will ever have much
of anything to show for having existed.
what of all the people younger than me possible making more impressive
achievements?...
one gets overrun and one gets replaced...

like middle or high schoolers or such who can pull off maybe 200 or
300 kloc/year or more?...
maybe they can write impressive stuff, or make interesting
discoveries?...

it has been much of a year, and my compiler has not even broken 100
kloc yet.

taking my average rate calculated earlier this year, and estimating
for a full year, it comes out to about 100kloc/year, which is probably
rather lame...

Believe it or not you still seem to be _far_ above average with regards
to programming, for someone of such youth. It _very_ impressive for
someone of 25 years of age to have written multiple compilers and GCs.
 
C

CBFalconer

cr88192 said:
.... snip ...

I remember when I was back in HS or so and heard about x86-64 (I
was like, cool, a 64 bit chip that there is actually reason to
use...), but it took so long in comming out, me getting one, and
am still waiting for good OS support, ...

Well, it looks like you are using Microsoft junk, and they will
never produce a good OS. I suspect that moving to Linux will
rapidly satisfy you.
</BLAST>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top