«

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);
}

-Sachin

<> wrote in message
news: ups.com...
> 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);
> }

You've entered the realm of undefined behaviour with the printf, and
anything at all (including printing h on stdout) can happen. Simply don't do
it.

<> wrote in message
news: ups.com...
> Hi,
>
> Why I am not getting any run time error while accessing a freed memory
> in following code.

C does not have any "run-time-errors". Accessing freed (i.e. non-allocated)
memory results in undefined behavior. If pink rabbits would jump out of your
computer, there would still be nothing wrong as far as the standard is
concerned.

> 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);

If that would print the content of the last issue of PlayGirl, it would be
right, too.
> }

Checkout the FAQ.

http://www.eskimo.com/~scs/C-faq/q7.20.html

dandelion wrote:
> C does not have any "run-time-errors". Accessing freed (i.e.
non-allocated)
> memory results in undefined behavior. If pink rabbits would jump out
of your
> computer, there would still be nothing wrong as far as the standard
is
> concerned.
> If that would print the content of the last issue of PlayGirl, it
would be
> right, too.
> > }

ROTFL. Pink Rabbits (?), PlayGirl(!) issue...

<> wrote in message
news: 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.

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

-Mike

wrote:
> Hi,
>
> Why I am not getting any run time error while accessing a freed memory
> in following code.

Dumb luck. Just as using malloc() and free() without the prototypes
found in <stdlib.h> and using strcpy without the prototype <string.h>
gave you no error.

> This is printing h in std output.

Not for me. A version of your program with other errors corrected
follows yours; note that the output is not what you claim.
>
> #include<stdio.h>
> main()
> {
> char* buffer = (char*)malloc(6);
> strcpy(buffer,"hello");
> free(buffer);
> printf("buffer=%c\n", *buffer);
> }

#include <stdio.h>
#include <stdlib.h> /* note */
#include <string.h> /* note */

int main(void)
{
char *buffer = malloc(6); /* note */
if (!buffer) {
fprintf(stderr, "malloc failed.\n");
exit(EXIT_FAILURE);
}
strcpy(buffer, "hello");
free(buffer);
printf("buffer=%c\n", *buffer); /* impromper use of pointer */
return 0;
}

[output]
buffer=

BTW: please note the other threads on preserving indenting when using
google.com. You can follow those suggestions or -- even better -- stop
using google for posting.

"Taran" <> wrote in message
news: oups.com...
>
> dandelion wrote:
> > C does not have any "run-time-errors". Accessing freed (i.e.
> non-allocated)
> > memory results in undefined behavior. If pink rabbits would jump out
> of your
> > computer, there would still be nothing wrong as far as the standard
> is
> > concerned.
> > If that would print the content of the last issue of PlayGirl, it
> would be
> > right, too.
> > > }
>
> ROTFL. Pink Rabbits (?), PlayGirl(!) issue...

Hey! Can't a girl have some fun, too? .

On Wed, 12 Jan 2005 18:13:15 +0000, Mike Wahler wrote:

> <> wrote in message
> news: ups.com...

....

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

Well, an int to a pointer. But that's not the problem. The code invokes
undefined behaviour because it tries to call a function with a type that
is not compatible with the function's definition. So the code has left the
rails before the cast is executed.

Lawrence

"dandelion" <> wrote in message
news:41e6464e$0$189$4all .nl...
>
> "Taran" <> wrote in message
> news: oups.com...
> >
> > dandelion wrote:
> > > C does not have any "run-time-errors". Accessing freed (i.e.
> > non-allocated)
> > > memory results in undefined behavior. If pink rabbits would jump out
> > of your
> > > computer, there would still be nothing wrong as far as the standard
> > is
> > > concerned.
> > > If that would print the content of the last issue of PlayGirl, it
> > would be
> > > right, too.
> > > > }
> >
> > ROTFL. Pink Rabbits (?), PlayGirl(!) issue...
>
> Hey! Can't a girl have some fun, too? .

In that case, I'd think you'd want not the 'content',
but the pictures.

"Honey, I buy 'em for the articles, honest!"



-Mike

Lawrence Kirby wrote:

>On Wed, 12 Jan 2005 18:13:15 +0000, Mike Wahler wrote:
>
>
>
>><> wrote in message
>>news: roups.com...
>>
>>
>
>....
>
>
>
>>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.
>>
>>
>
>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.

>undefined behaviour because it tries to call a function with a type that
>is not compatible with the function's definition. So the code has left the
>rails before the cast is executed.
>
>Lawrence
>
>
Krishanu