Do I need to free all memory that is malloced?

[karthik.nar]

suppose i have

char* ip = malloc(10);

and i use up only two bytes.

then can i free(ip+2)

the idea is that in case my program does not use up all the bytes
malloced, am i allowed to free up the unused bytes alone?

 

[ulrik.sverdrup]

Use realloc(ip, 2)

 

[Alexei A. Frounze]

suppose i have
char* ip = malloc(10);
and i use up only two bytes.
then can i free(ip+2)

the idea is that in case my program does not use up all the bytes
malloced, am i allowed to free up the unused bytes alone?

free (ip+2) is wrong. It shouldn't normally bring the system down, but it
will neither free *ip nor part of *ip.

There're only two ways:
1. free exactly what (as much as) you've allocated
2. reallocate (with realloc()) the block to make it bigger or smaller

Alex

 

[Bryan Donlan]

free (ip+2) is wrong. It shouldn't normally bring the system down, but it
will neither free *ip nor part of *ip.

On the contrary, it is very likely to cause the system to crash or some kind
of malloc asserts to be tripped. It's common to have some sort of pointer
immediately before a mallocced memory block, or at least a size indicator.

 

[Alexei A. Frounze]

Alexei A. Frounze wrote: ....

On the contrary, it is very likely to cause the system to crash or some kind
of malloc asserts to be tripped. It's common to have some sort of pointer
immediately before a mallocced memory block, or at least a size indicator.

The system will only crash if the user memory manager is dumb and there's no
memory protection employed in the CPU. On x86 the system (windows or linux)
won't crash if the user app does something like free(ip+2). On such a
system, the maximum problem that one may get is an exception and maybe
program termination.

As for the user memory manager (or libc's malloc/free), some sanity checks
are due anyway. The mm must check whether the pointer falls inside the range
of the address space where the memory is managed, whether the pointer points
to a beginning of a valid and allocated block. It shouldn't be very hard to
perform these checks. Even if an implementation of the mm does not catch all
100% of mm-related problems, many of them will be caught. If the control
information cannot be protected from the damage, some CRC-aided cheks will
help at least determine whether or not the control info is still valid.
If someone tells this would degrade the performance I'd agree, but then
again, a question naturally arises... Is the algorithm picked in the app
good enough at all if it's too dependent on the mm speed?

If we assume dumb programmers and their apps (actually, that should be
assumed as even experienced and good programmers sometimes do bad things,
most often accidentally and not because they didn't know something), we must
provide more or less stable and error-detecting basis for them, i.e. the
standard libraries, etc.

Alex

 

[Emmanuel Delahaye]

suppose i have

char* ip = malloc(10);

and i use up only two bytes.

then can i free(ip+2)

the idea is that in case my program does not use up all the bytes
malloced, am i allowed to free up the unused bytes alone?

No. The value to be passed to free() must be exactly match the value
received from malloc().

However, the allocated bloc can be shriked with realloc(). Be sure you
have alot of byte to spare because realloc() isn't cheap...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

 

[Bryan Donlan]

The system will only crash if the user memory manager is dumb and there's
no memory protection employed in the CPU. On x86 the system (windows or
linux) won't crash if the user app does something like free(ip+2). On such
a system, the maximum problem that one may get is an exception and maybe
program termination.

Well, okay, that's what I meant with crash. GNU libc actively aborts the
program when it detects this.

 

[Richard Bos]

free (ip+2) is wrong. It shouldn't normally bring the system down,

Very nearly nothing a mere user program does will bring a modern,
well-written OS down. Bringing your program down is another matter.

but it will neither free *ip nor part of *ip.

You don't know that; it causes undefined behaviour. Undefined behaviour
is allowed to do anything, and anything does include "appearing to
work". It also includes terminating the program with some kind of access
violation fault (while, of course, leaving the rest of the system
perfectly undisturbed), and in fact that may be the most common result.

There're only two ways:
1. free exactly what (as much as) you've allocated
2. reallocate (with realloc()) the block to make it bigger or smaller

And free() each realloc()ated block only once - do not free() both the
original _and_ the new pointer. In fact, once you've called realloc()
succesfully, forget about the original pointer entirely.

Richard

 

[Charles Sullivan]

On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:

However, the allocated bloc can be shriked with realloc(). Be sure you
have alot of byte to spare because realloc() isn't cheap...

Can you expound on this a little? Is the memory used by realloc()
at any one time substantially greater than the old allocation
plus the new allocation? And isn't the old allocation freed?

 

[Emmanuel Delahaye]

Charles Sullivan wrote on 26/09/05 :

On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:


Can you expound on this a little? Is the memory used by realloc()
at any one time substantially greater than the old allocation
plus the new allocation? And isn't the old allocation freed?

If you are to spare just a few bytes, don't call realloc(). It costs in
terms of
- development (the good use of realloc() is not trivial, see the FAQ)
- time execution (realloc() can be a slow function)

Not to mention that in most cases, the gain is close to 0 because the
'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
all a matter of implementation.



--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."

 

[Mark McIntyre]

On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,

Very nearly nothing a mere user program does will bring a modern,
well-written OS down.

That the funniest thing I've heard this year!

Dont try this at home
$ sudo root
$ rm -rf /

(root is a user too, you know...)

 

[Keith Thompson]

On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,


That the funniest thing I've heard this year!

Dont try this at home
$ sudo root
$ rm -rf /

(root is a user too, you know...)

$ sudo root
sudo: root: command not found

But yes, I see what you mean.

All you've done here is illustrate the difference between "very nearly
nothing" and "nothing".

It would be more accurate to say that very nearly nothing a user
program running without elevated privileges does will bring down a
modern OS. There are, of course, exceptions (OS bugs,
denial-of-service attacks, etc.).

The narrower point here is that calling free() with an invalid pointer
(e.g., "p = malloc(whatever); free(p+2);") is likely to crash the
individual program, but is highly unlikely to crash the entire OS.

But that's far beyond anything the C standard guarantees, or even
discusses. There may or may not even be an OS. Either way, an
invalid free() invokes undefined behavior; if it *does* crash the OS,
it's the OS's fault, not C's fault.

 

[Richard Bos]

On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,


That the funniest thing I've heard this year!

Dont try this at home
$ sudo root
$ rm -rf /

(root is a user too, you know...)

"Very nearly nothing" and "a mere user program" do kinda imply "not
actively suicidal", really.

Richard

 

[Ian Malone]

Charles Sullivan wrote on 26/09/05 :



If you are to spare just a few bytes, don't call realloc(). It costs in
terms of
- development (the good use of realloc() is not trivial, see the FAQ)

The only reference I can see in the clc faq is to passing null
to realloc. The only gotcha I'm aware off with respect to realloc
is the need to check the return value before changing the pointer,
so it requires a temporary variable. That seems fairly trivial.

- time execution (realloc() can be a slow function)

This is certainly true on implementations I've used,
I would guess shrinking is faster than expanding
(probably no need to move and therefore no need to
copy the allocated memory). 100% implementation
dependant of course.

Not to mention that in most cases, the gain is close to 0 because the
'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
all a matter of implementation.

Indeed, I'm not sure realloc is even guaranteed to free
the released memory for further use[1]. Whether it's
worth doing probably depends on your overestimation
of the array size.

[1] Except in this case: "If the realloc function returns a
null pointer when size is zero and ptr is not a null
pointer, the object it pointed to has been freed."

 

[Anonymous 7843]

Very nearly nothing a mere user program does will bring a modern,
well-written OS down.

int main(void)
{
while(1)
{
malloc(1000000);
fork();
}
}

/* Sure, it's not conforming, but neither is free(ip+2). */

 

[Alexei A. Frounze]

int main(void)
{
while(1)
{
malloc(1000000);
fork();
}
}
/* Sure, it's not conforming, but neither is free(ip+2). */

Even w/o fork() it can be very bad (depends on the system) and yet be
conforming...

Alex

 

[embedhere]

Charles Sullivan wrote on 26/09/05 :



If you are to spare just a few bytes, don't call realloc(). It costs in
terms of
- development (the good use of realloc() is not trivial, see the FAQ)

The only reference I can see in the clc faq is to passing null
to realloc. The only gotcha I'm aware off with respect to realloc
is the need to check the return value before changing the pointer,
so it requires a temporary variable. That seems fairly trivial.

- time execution (realloc() can be a slow function)

This is certainly true on implementations I've used,
I would guess shrinking is faster than expanding
(probably no need to move and therefore no need to
copy the allocated memory). 100% implementation
dependant of course.

Not to mention that in most cases, the gain is close to 0 because the
'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
all a matter of implementation.

Indeed, I'm not sure realloc is even guaranteed to free
the released memory for further use[1]. Whether it's
worth doing probably depends on your overestimation
of the array size.

[1] Except in this case: "If the realloc function returns a
null pointer when size is zero and ptr is not a null
pointer, the object it pointed to has been freed."

Hello Friends,
Can somebody come up with a code snippet for the same?
Thanks,
Balakrishna

 

[Michael Wojcik]

int main(void)
{
while(1)
{
malloc(1000000);
fork();
}
}

/* Sure, it's not conforming, but neither is free(ip+2). */

That won't cause a problem for a modern, well-written, correctly
configured OS. Properly configured POSIX systems have reasonable
resource limits set.

For that matter, most of the modern POSIX systems I use deal
relatively well with resource exhaustion - they certainly don't go
down. They may have to kill off some noncritical processes, but
the OS itself stays running.

--
Michael Wojcik (e-mail address removed)

Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!

 

[Anonymous 7843]

That won't cause a problem for a modern, well-written, correctly
configured OS. Properly configured POSIX systems have reasonable
resource limits set.

For that matter, most of the modern POSIX systems I use deal
relatively well with resource exhaustion - they certainly don't go
down. They may have to kill off some noncritical processes, but
the OS itself stays running.

I've tried out the above snippet on dozens of unix/posix/linux
machines. You're right, they don't always crash, but more often
than not the machine is essentially unusable and needs to be
rebooted. Perhaps it is just my bad luck to encounter only
incorrectly configured systems; or the number of correctly
configured systems is lower than ideal.

 

[Randy Howard]

Mark McIntyre wrote

On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,


That the funniest thing I've heard this year!

Dont try this at home
$ sudo root
$ rm -rf /

(root is a user too, you know...)

$ sudo cat < /dev/zero > /dev/mem

is pretty exciting, and much faster.