Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > accessing freed memory without error

Reply
Thread Tools

accessing freed memory without error

 
 
Lawrence Kirby
Guest
Posts: n/a
 
      01-14-2005
On Thu, 13 Jan 2005 21:53:36 +0530, Krishanu Debnath wrote:

....

>>Well, an int to a pointer. But that's not the problem. The code invokes
>>

> Just wondering what will happen in a 64 bit m/c? 32 bit integer may yield a
> junk 64 bit pointer value. Because 64 bit return value of malloc has now
> truncated to 32 bit integer.


It is impossible to say what will happen. There's no requrement that an
int and a pointer return value even be returned in the same place. For
example 68000 series processors have different data and address registers
so an integer value might be returned in D0 and a pointer in A0. Code that
casts from the wrong return type will likely end up looking in the wrong
place completely for the value.

Lawrence
 
Reply With Quote
 
 
 
 
Dave Thompson
Guest
Posts: n/a
 
      01-17-2005
On Wed, 12 Jan 2005 18:13:15 GMT, "Mike Wahler"
<(E-Mail Removed)> wrote:

> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...

<other good comments snipped>
> > char* buffer = (char*)malloc(6);

<snip>
> Also, your casting of 'malloc()'s return value hides a
> serious error: There's no prototype for 'malloc()' in
> scope, which will cause a C89 compiler to assume it
> returns type 'int'. So your cast tries to convert
> a pointer type to an integer type. The language


You mean integer to pointer.

> does not define such a conversion. This conversion
> is implementation-defined, but in any case it will


Right so far.

> very likely corrupt the returned pointer value, in
> which case you have more undefined behavior.
>

Actually if probability is measured over platforms, it "very likely"
will work "accidentally" -- on most platforms pointers are just
addresses and addresses are really integers. But it isn't required to
work by the standard, and you shouldn't rely on it.

The implicit misdeclaration also provides two (more) sources of
Undefined Behavior. malloc actually returns a pointer (void *) while
the calling code expects it to return an int, which is then converted
as discussed already. And its parameter is size_t, but the actual
argument here is int, and without the prototype declaration isn't
automatically converted. It is not required that the mechanisms for
returning and passing different types be the same, but again, on many
platforms they are and this "accidentally" works, although I would say
not quite as often as the conversion. And certainly not guaranteed.

- David.Thompson1 at worldnet.att.net
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      01-17-2005
Mike Wahler wrote:
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
>
>>Hi,
>>
>>Why I am not getting any run time error while accessing a freed memory
>>in following code.

>
>
> Because your program's behavior is undefined. This means
> that from the language perspective, it could do absolutely
> anything at all, from 'seems to work', to a crash, anything
> in between, or something else.
>
>
>>This is printing h in std output.

>
>
> It also might have caused the monitor to fall of the desk.
> Moral: Don't Do That.
>
>
>>#include<stdio.h>

>
>
> #include <stdlib.h> /* declares 'malloc()' and 'free()' */
> #include <string.h> /* declares 'strcpy()' */
>
>
>>main()

>
>
> int main(void)
>
>
>>{
>>char* buffer = (char*)malloc(6);

>
>
> You forgot to check if 'malloc()' succeeded. If it
> failed, it returns NULL, in which case the call
> to 'strcpy()' would give undefined behavior, because
> it would try to dereference a null pointer.
>
> Also, your casting of 'malloc()'s return value hides a
> serious error: There's no prototype for 'malloc()' in
> scope, which will cause a C89 compiler to assume it
> returns type 'int'. So your cast tries to convert
> a pointer type to an integer type. The language
> does not define such a conversion. This conversion
> is implementation-defined, but in any case it will
> very likely corrupt the returned pointer value, in
> which case you have more undefined behavior.


It's worse than that, it is guaranteed to be undefined behaviour because
malloc returns a void* but the OP has effectively lied to the compiler
by making it assume an int is returned, there is no integer to pointer
conversion invoked. It is perfectly reasonable and valid for and int to
be returned in one register and a pointer in a different register,
something that some implementations definitely do. So this could cause
some random value that happens to be in a data register to be converted
to a pointer whilst the actual return value is completely ignored.

>>strcpy(buffer,"hello");
>>free(buffer);
>>printf("buffer=%c\n", *buffer);

>
>
> return 0;
>
>
>>}

>
>
> It's been a while since I've seen so many errors in such
> a small piece of code.


Yes, it was horrendous, and very similar to lots of other such examples
I've seen posted asking the same question.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-17-2005
Dave Thompson wrote:
> [concerning the use of malloc() without a declaration]
>
> The implicit misdeclaration also provides two (more) sources of
> Undefined Behavior. malloc actually returns a pointer (void *) while
> the calling code expects it to return an int, which is then converted
> as discussed already. And its parameter is size_t, but the actual
> argument here is int, and without the prototype declaration isn't
> automatically converted. It is not required that the mechanisms for
> returning and passing different types be the same, but again, on many
> platforms they are and this "accidentally" works, although I would say
> not quite as often as the conversion. And certainly not guaranteed.


The not-really-`int' to pointer conversion is particularly
likely to produce garbage on an implementation where `int' is
narrower than `void*'. Implementations with 32-bit `int' and
64-bit `void*' are not difficult to find.

Similarly, the failure to convert `int' to `size_t' is
likely to garble the argument on implementations where `size_t'
is wider than `int', particularly if the system uses something
like a "register pair" to hold the wider quantity. And once
again, such systems are not hard to find: 32-bit `int' and 64-bit
`size_t' is a fairly common combination.

In short, I agree with Dave's "certainly not guaranteed,"
except that I would have disouraged the practice even more
strongly. Fortunately, C99 offers the strongest discouragement
of all: Calling malloc() without a prior declaration is now a
flat-out compile-time error, requiring a diagnostic.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
bd
Guest
Posts: n/a
 
      01-17-2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(E-Mail Removed) wrote:

> Hi,
>
> Why I am not getting any run time error while accessing a freed memory
> in following code. This is printing h in std output.
>
> #include<stdio.h>
> main()
> {
> char* buffer = (char*)malloc(6);
> strcpy(buffer,"hello");
> free(buffer);
> printf("buffer=%c\n", *buffer);
> }


The effects of accessing freed memory are undefined. This means anything can
happen, including nothing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFB7Bmx+hz2VlChukwRAuvUAKC0oI2YJBXOxsWO4rAzSq wer8/YtQCfVBfR
lIVTC8MC9YidBIuG9GPcErg=
=TQbd
-----END PGP SIGNATURE-----
 
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
destroy primitive/object types but memory is not freed george972@mailinator.com C Programming 5 05-25-2009 10:44 PM
why 50% of allocated memory is not freed? MN C Programming 32 03-11-2009 03:40 PM
Detecting freed memory Rob C Programming 6 09-01-2005 07:39 PM
How to know the memory pointed by a ptr is freed? ravi C Programming 72 09-14-2004 01:13 PM
use delete to destroy primitive/object types but memory is not freed jimjim C Programming 28 04-13-2004 11:34 PM



Advertisments