Querry (Newbe)

[ranjeet.gupta]

Dear All

As I was going through the Recent replies on the realloc(),
I got some question and my annalysis on that, so regarding on these
please guide me where I fail on the theoritical and practical
Knowledge. I am not able to read all the thread in the replies as
due to some problem in the web server.

Point 1.

If we do the realloc then it means that we have allocated the
extended memory for the current memory, for which we have
reallocated it. Means I need not to free the previous memory
which I extendend to realloc if compiler allocates memory
(extended memory) from the place where intial memory was allocated.

And we need to free if the memory is allocated by the
(realloc)in the new region.

so the key is to always free the memory when you reallocate
the memory by realloc fucntion.

How much I am correct on the Point 1 ?

Point 2.

what is the diffrence between the calloc() and malloc()
As far As I know the basic diffrence is that
1. malloc takes 1 argumnets while calloc takes two
2. malloc initialise the memory with the garbage values while
calloc initialise it with 0 (Zero)
3. malloc allocates continious memeory i.e one Block while
calloc alloactes into the Block
calloc (100, 2) ,means two block of 100 memoty alloaction.

apart from the above is any more diffrence between them ??

Point 3.

This may be looks off topic to you but I have one thing to ask
is there any diffrence between the malloc and new ??

Point 4.

why we need to derefrence the pointers once we are are done with our
work; I am not aware of garbage collection, And where I can find the
memory leak into the program ?

Thanks In Advance
Regards
Ranjeet

 

[Eric Sosman]

Dear All

As I was going through the Recent replies on the realloc(),
I got some question and my annalysis on that, so regarding on these
please guide me where I fail on the theoritical and practical
Knowledge. I am not able to read all the thread in the replies as
due to some problem in the web server.

Point 1.

If we do the realloc then it means that we have allocated the
extended memory for the current memory, for which we have
reallocated it. Means I need not to free the previous memory
which I extendend to realloc if compiler allocates memory
(extended memory) from the place where intial memory was allocated.

And we need to free if the memory is allocated by the
(realloc)in the new region.

so the key is to always free the memory when you reallocate
the memory by realloc fucntion.

How much I am correct on the Point 1 ?

If realloc() copies the old memory to a new region,
realloc() releases the old region. You must not try to
release it yourself.

Point 2.

what is the diffrence between the calloc() and malloc()
As far As I know the basic diffrence is that
1. malloc takes 1 argumnets while calloc takes two
2. malloc initialise the memory with the garbage values while
calloc initialise it with 0 (Zero)
3. malloc allocates continious memeory i.e one Block while
calloc alloactes into the Block
calloc (100, 2) ,means two block of 100 memoty alloaction.

apart from the above is any more diffrence between them ??

You are correct on 1 and 2. For 3, there is no difference:
calloc() allocates one contiguous block, just as malloc() does.

Point 3.

This may be looks off topic to you but I have one thing to ask
is there any diffrence between the malloc and new ??

Yes: malloc() is a Standard library function, and `new'
is an identifier that you can use in your program for any
purpose you like. (There is a Different Language in which
`new' has special significance, but the Different Language
is off-topic here.)

Point 4.

why we need to derefrence the pointers once we are are done with our
work; I am not aware of garbage collection, And where I can find the
memory leak into the program ?

I'm sorry, but I do not understand this question or
questions.

 

[Keith Thompson]

Point 2.

what is the diffrence between the calloc() and malloc()
As far As I know the basic diffrence is that
1. malloc takes 1 argumnets while calloc takes two
2. malloc initialise the memory with the garbage values while
calloc initialise it with 0 (Zero)
3. malloc allocates continious memeory i.e one Block while
calloc alloactes into the Block
calloc (100, 2) ,means two block of 100 memoty alloaction.

apart from the above is any more diffrence between them ??

Eric Sosman has already written most of what I would have, but I'd
like to make one additional point.

calloc initializes the allocated block to all-bits-zero. This is not
necessarily useful. If the allocated block is to be used as an array
of unsigned char, you're guaranteed that the elements of the array
will have the value 0. If it's to be used as an array of some other
integer type, you're *practically* guaranteed the same thing; the
standard doesn't explicitly state that all-bits-zero is a valid
representation for the value 0, but I think there's been a more recent
ruling from the committee that it is.

For other types (particularly floating-point and pointer types),
there's no guarantee that all-bits-zero is a valid value. On many
systems, setting a floating-point variable to all-bits-zero will
result in the value 0.0, and setting a pointer variable to
all-bits-zero will result in a null pointer, *but* this is not
guaranteed and you shouldn't assume it. It's likely to work correctly
during testing, then fail mysteriously when you port it to another
implementation and you've forgotten your initial assumptions.

If you want the allocated memory to be initialized to some meaningful
value, you should do it yourself rather than depending on calloc (or
memset, or whatever) to do it for you. There are cases where you can
depend on calloc to do the right thing, but in general it's safest to
assume that it fills the allocated block with garbage -- in which case
you might as well use malloc() rather than calloc().

 

[Robert Gamble]

Eric Sosman has already written most of what I would have, but I'd like
to make one additional point.

calloc initializes the allocated block to all-bits-zero. This is not
necessarily useful. If the allocated block is to be used as an array of
unsigned char, you're guaranteed that the elements of the array will
have the value 0. If it's to be used as an array of some other integer
type, you're *practically* guaranteed the same thing; the standard
doesn't explicitly state that all-bits-zero is a valid representation
for the value 0, but I think there's been a more recent ruling from the
committee that it is.

Indeed, Technical Corrigendum 2 of the C99 Standard says this in item #9:

Page 39, 6.2.6.2
Append to paragraph 5:
For any integer type, the object representation where all the bits are
zero shall be a representation of the value zero in that type.

Rob Gamble

 

[Robert Gamble]

(e-mail address removed) wrote: [snip]

Point 4.

why we need to derefrence the pointers once we are are done with our
work; I am not aware of garbage collection, And where I can find the
memory leak into the program ?

I'm sorry, but I do not understand this question or
questions.

I can come up with two interpretations here.

The first is: "Why can't we dereference pointers that point to memory that
has been freed since there is no garbage collection system to re-use the
memory?"

The second is: "Why do we have to assign a NULL value to a pointer that
points to free'd memory?"

My answer to the former would be: Because the Standard says so. Some
implementations may, for example, return memory back to the operating
system. In any case, no guarantees are made by the Standard regarding the
free'd memory except that attempting to access it invokes undefined
behavior.

My answer to the latter would be: You don't have to but some consider it
good practice as it may help clarify code and improve debugging efforts.

If neither of the interpretations is correct, the OP should rephrase the
question.

Rob Gamble

 

[Walter Roberson]

I can come up with two interpretations here.

The first is: "Why can't we dereference pointers that point to memory that
has been freed since there is no garbage collection system to re-use the
memory?"

My answer to the former would be: Because the Standard says so. Some
implementations may, for example, return memory back to the operating
system. In any case, no guarantees are made by the Standard regarding the
free'd memory except that attempting to access it invokes undefined
behavior.

Adding a bit to that:

a) Having a garbage collection system of some sort is perfectly valid
and fairly common.

b) It is common for the memory allocator to use the space occupied by
the freed memory in order to store information needed by the allocator.
For example, the allocator might store the address of the next free
chunk of memory, so that it can chase through the list in order to find
available memory;

c) The C standard only allows C programmers to access within objects,
and once memory is freed it is no longer part of an object; thus
accessing that memory will have undefined results;

d) For the -typical- C allocator, returning memory back to the
operating system is fairly unusual, as it typically is too much overhead
to figure out whether there might be memory further along that is still
in use; this fits in with the traditional Unix "memory growth is
always after the last allocated memory" paradigm.

e) It is acceptable behaviour within the standard for
the memory allocator to allocate in distinct virtual memory "pages" and to
keep track of the use of the page, and to return the virtual page to
the operating system when the page is no longer in use. This may
result in holes in the logical address space, but that's irrelevant
because the standard places tight constraints on accessing outside of
valid existing objects. This has been implemented on real systems.

There are advantages and disadvantages to each of (d) and (e).

f) On some real systems (e.g., the DEC VAX), each "pointer" is
not just an address but a key to a memory descriptor, with hardware
or software protection that -prevents- you from accessing out of bounds.
When you have freed a pointer, the memory descriptor may thereafter
be garbage or may be specifically set to a descriptor that will cause
a fault.

g) Keep in mind that a pointer is not necessarily a number as such.
You should not think of it as strictly a byte (or word) count from the
beginning of RAM. A pointer may be a semi-opaque value with no inherent
meaning, with a look-up table of some sort determining what the
pointer refers to. If you look at what you can legally do with
pointers, you will find that it is even possible for "the same pointer"
to refer to different parts of memory in different code sections -- so
once you have free()'d a pointer, there is no certainty at all about
-what- it refers to!