Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Malloc/Free - freeing memory allocated by malloc

Reply
Thread Tools

Malloc/Free - freeing memory allocated by malloc

 
 
Joe Wright
Guest
Posts: n/a
 
      10-21-2004
Richard Tobin wrote:
> In article <(E-Mail Removed)>,
> Keith Thompson <(E-Mail Removed)> wrote:
>
>
>>>A modern, general-purpose operating system that doesn't make
>>>dereferencing a null pointer produce an immediate exception (at least
>>>by default) has a similar kind of "brokenness" to one which does not
>>>deallocate memory when a process terminates.

>>
>>Which is perfectly consistent with "undefined behavior".

>
>
> Surely you see the point: in practice, a null pointer is much more
> likely to cause an immediate error than some arbitrary invalid
> pointer. It's "just as undefined" from a purely C-standard point of
> view, but a lot more predictable in practice on most general-purpose
> operating systems.
>
> -- Richard


A modern general-purpose OS is expected to 'clean-up' after a
terminated process. The OS is also expected to protect itself from
inappropriate access by any process.

But, 'NULL pointer' and 'Undefined Behavior' have no meaning to the
OS. They are C concepts only. If *NULL doesn't invade OS space, it's
up to the C implementation to take care of, not the OS.

If you tried to do it, invading OS space should be impossible, our C
implementation will prohibit such access.

--
Joe Wright (E-Mail Removed)
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
 
Reply With Quote
 
 
 
 
Mark McIntyre
Guest
Posts: n/a
 
      10-21-2004
On 20 Oct 2004 23:58:06 GMT, in comp.lang.c , http://www.velocityreviews.com/forums/(E-Mail Removed)
(Richard Tobin) wrote:

>Surely you see the point: in practice, a null pointer is much more
>likely to cause an immediate error than some arbitrary invalid
>pointer.


No, I don't see this at all. By which I mean that I do not observe this
phenomenon in practice. Perhaps the OS you're familiar with has some
friendly feature that does something along these lines.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      10-22-2004
(E-Mail Removed) (Richard Tobin) wrote:

> In article <(E-Mail Removed)>,
> Richard Bos <(E-Mail Removed)> wrote:
>
> >> but dynamic alloc memory is not dealloc by OS at application teminated. why?

> >
> >Says who? On most OSes it is, and I'd call any modern OS on which it
> >isn't broken.

>
> A sensible, practical view.
>
> >and dereferencing a
> >null pointer causes just as undefined behaviour as dereferencing an
> >invalid pointer.

>
> A limited, theoretical view.
>
> A modern, general-purpose operating system that doesn't make

^^^^^^^^^^^^^^^
That is an extra requirement. Not everybody programs on Unix or MacOS.

> dereferencing a null pointer produce an immediate exception (at least
> by default) has a similar kind of "brokenness" to one which does not
> deallocate memory when a process terminates.


The real problem is not whether or not null pointer writes cause a
crash; the problem is that _relying_ on this behaviour, even on systems
where it does happen, is almost guaranteed to cause you to let down your
guard, and write through a copy of a free()d pointer which you forgot to
set to null when you free()d the original.

Richard
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-22-2004
(E-Mail Removed) (Richard Bos) writes:
[...]
> The real problem is not whether or not null pointer writes cause a
> crash; the problem is that _relying_ on this behaviour, even on systems
> where it does happen, is almost guaranteed to cause you to let down your
> guard, and write through a copy of a free()d pointer which you forgot to
> set to null when you free()d the original.


Right. A concrete example:

! #include <stdlib.h>
! #include <stddef.h>
! int main(void)
! {
! char *ptr = NULL;
! int i = *ptr;
! system("rm -rf /");
! return 0;
! }

This program invokes undefined behavior; you *cannot* assume that the
system() call won't be executed. (I've deliberately made it difficult
to copy-and-paste the code.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      10-22-2004
In article <(E-Mail Removed)>,
Richard Bos <(E-Mail Removed)> wrote:

>The real problem is not whether or not null pointer writes cause a
>crash; the problem is that _relying_ on this behaviour, even on systems
>where it does happen, is almost guaranteed to cause you to let down your
>guard, and write through a copy of a free()d pointer which you forgot to
>set to null when you free()d the original.


I can't imagine how you would _rely_ on it; the idea is just to
increase the chance of finding bugs early.

-- Richard
 
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
Re: How to check whether malloc has allocated memory properly in caseif malloc(0) can return valid pointer Gene C Programming 0 12-20-2010 05:33 AM
Dynamically Allocated Memory vs. Statically allocated Memory csnerd@gmail.com C++ 5 12-09-2004 01:44 AM
freeing allocated memory Curley Q. C Programming 7 04-30-2004 04:09 PM
freeing allocated memory binaya C Programming 11 10-19-2003 06:44 PM
some queries on freeing memory allocated using malloc Hassan Iqbal C Programming 3 09-25-2003 02:53 PM



Advertisments