what will happen after i use free()???

[neilcancer]

i come from china,and i'm sorry that my english is very poor.

now i'm studing data structure and i met some problem about c language.

could you tell me what will happen after i use free()? i mean once i
use free() on a pointer,what will the pointer points to ?

for example:

#include<stdio.h>
#include<stdlib.h>

void main()

{

int *p;
if(!p) printf("good");
else printf("fail");
p=(int *)malloc(100);
if(p) printf("\n\ngood");
else printf("\n\nfail");

free(p);
if(!p) printf("\n\ngood");
else printf("\n\nfail");

*p=100;
printf("\n\n%d",*p);
}

the result is:

fail

good

fail

100

why?

[Herbert Rosenau]

On Sun, 19 Mar 2006 17:58:58 UTC, Jordan Abel <ra*******@gmail.com>
wrote:

On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote:

On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Sun, 19 Mar 2006 08:54:20 +0000 (UTC), in comp.lang.c , "Herbert
Rosenau" <os****@pc-rosenau.de> wrote:

> (<any cast>) malloc() results in
>undefined behavor, p=malloc() is the only secure call allowed in C.

Rubbish. Inserting a cast before malloc is not needed, but doesn't
result in UB.
You should program under an environment that would use for return
valuses of different types different locations and then use casting on
functions returning other than int, forgetting to #include stdlib you
gets undefined behavior

The undefined behavior is not caused by the cast, and would happen
without it.

So far so right - but it will hide the diagnostic that would at least
help to fix the problem, even as the diagnostic message itself may
irretate an beginner. The cast will noways able to fix the real
problem and is at least a problem on itself.

>There is under absolutely no circomstance a need for a cast of (void*)
>to anything else.

variadic functions?

That'd be more likely to need to be a cast TO void * than FROM void *.
Or a cast of a null pointer constant, which could just as easily be 0 as
(void*)0.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Jordan Abel]

On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote:

On Sun, 19 Mar 2006 17:55:16 UTC, Jordan Abel <ra*******@gmail.com>
wrote:

> I still don't think casting the result off `malloc()` results in
> undefined behaviour. Why would it? Remember, we were talking about
> casting to a different /pointer/ type, not just /any/ type.

Correct. If the cast masks an error message, the undefined behavior has
already happened.

No, the cast is to hide any diagnostic - it is still a lie to the
compiler.

The cast is not the lie. The implicit declaration is the lie.

[Jordan Abel]

On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote:

On Sun, 19 Mar 2006 15:12:17 UTC, ri*****@cogsci.ed.ac.uk (Richard
Tobin) wrote:

In article <wm***************************@URANUS1.DV-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.de> wrote:

>You should program under an environment that would use for return
>valuses of different types different locations and then use casting on
>functions returning other than int, forgetting to #include stdlib you
>gets undefined behavior

Using malloc() without a declaration will cause undefined behaviour,
but casting the result of malloc() will not. The main problem with
casting it is that it may disguise the fact that it's not declared.

You're in error. Who guarantees that your compiler will give you
exactly the same bits in the same meaning that malloc returns? There
are many reasons why the cast of the result of the undecleard malloc
give you something that is absolutely independant from the value
malloc has given back to the caller -> undefined behavior is
guaranteed.

The undefined behavior has ALREADY HAPPENED, though. The only undefined
behavior involved is the call to an incorrectly declared function.
Conversion from int to pointer is not itself undefined, it's
implementation-defined.

[Vladimir S. Oka]

Herbert Rosenau opined:

On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka"
<no****@btopenworld.com> wrote:

Herbert Rosenau opined:

> On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre
> <ma**********@spamcop.net> wrote:
>
>> On Sun, 19 Mar 2006 08:54:20 +0000 (UTC), in comp.lang.c ,
>> "Herbert Rosenau" <os****@pc-rosenau.de> wrote:
>>
>> > (<any cast>) malloc() results in
>> >undefined behavor, p=malloc() is the only secure call allowed in
>> >C.
>>
>> Rubbish. Inserting a cast before malloc is not needed, but
>> doesn't result in UB.
>
> You should program under an environment that would use for return
> valuses of different types different locations and then use
> casting on functions returning other than int,
Again, can you please elaborate /why/ you think this matters
(physical storage of return values)?

C Standard C makes absolutely no assumption how an implementation
should handle such things as returning values from functions. So each
implementation does it in a way best resolved by the underlying
hardware. Intel on on that aspect one of the littlest market ever
seen even as M$ means that they have the mayority.

OK, I think where the disconnect is.

We both agree that casting the return from `malloc()` is a Bad Thing.

Where we seem to disagree seems to be where the UB comes from if
<stdlib.h> is not included.

You seem to think it's the cast that does it.

I, OTH, think that UB has already happened *before*, and independently
of the cast. Cast may just hide the diagnostic that may have warned
you of the problem. (FWIW, it does seem that a few other people here
share my view.)

< big snip >

Apart from calling people names again, you also forgot to breathe.
Your posts are increasingly resembling any of the dozens of
definitions of flaming. You risk becoming a troll...

That doesn't disturb me. Only trolls will name others who tries to
teach a troll.

I may have over-reacted.
Here you'll see nearly dayly an idiot who means that casting to hide
diagnostics is ok. True, many peoples coming here have learned that
by reading defektive books, broken code from idiots, so I try to help
them to get it right whenever I have free time to do so.
You seem to have quite a lot at the moment. ;-)
As this thread is running for more than a week now I get allergic to
read again and again therin casting results returning from functions
like malloc is ok.
I don't think anyone was arguing that. I know I wasn't.
It looks like there is a need to drum into somebody that casting is
almost the wrongest method to resolve a problem.
It does have its uses, though.
Use cast only if you are absolutely sure that yor really needs the
cast and after you have checked and rechecked again and again that
you really knows what you does and not on the way to lie to the
compiler. lie to the compiler and it will get its dreadful revange.
As others have pointed out, in the case we were discussing, it's not
the cast that is lying, rather not including <stdlib.h> is.
Myself had learned that more than 20 years ago even on K&RII by
falling through cede inspections, failing on getting the results I
expected before I learned how to use casts right. There was no usenet
ready to learn from others.

Why does this suddenly reminds me of the Yorkshiremen joke... ;-)

--
BR, Vladimir

SERENDIPITY:
The process by which human knowledge is advanced.

[Stefan Krah]

* Herbert Rosenau <os****@pc-rosenau.de> wrote:

Here you'll see nearly dayly an idiot who means that casting to hide
diagnostics is ok. True, many peoples coming here have learned that by
reading defektive books, broken code from idiots, so I try to help
them to get it right whenever I have free time to do so.

Many people learn the malloc cast from K&R 2nd edition and this link
would help more than calling them idiots:

http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html
Stefan Krah

[Richard Tobin]

In article <wm***************************@URANUS1.DV-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.de> wrote:

You're in error. Who guarantees that your compiler will give you
exactly the same bits in the same meaning that malloc returns? There
are many reasons why the cast of the result of the undecleard malloc
give you something that is absolutely independant from the value
malloc has given back to the caller -> undefined behavior is
guaranteed.

Using the return value from an undeclared malloc *at all* will produce
undefined behaviour. Even if you don't cast it. The cast doesn't make
the behaviour any more undefined.

Conside the following fragments covering all the possibilities of
whether malloc is declared and whether the result is cast:

(1) #include <stdlib.h>
...
int *p = malloc(sizeof(*p));

(2) #include <stdlib.h>
...
int *p = (int *)malloc(sizeof(*p));

(3) /* no declaration of malloc */
...
int *p = malloc(sizeof(*p));

(4) /* no declaration of malloc */
...
int *p = (int *)malloc(sizeof(*p));

Which ones produce undefined behaviour? Does the presence of the cast
make any difference?

-- Richard

[Richard Bos]

"Herbert Rosenau" <os****@pc-rosenau.de> wrote:

On Sun, 19 Mar 2006 17:58:58 UTC, Jordan Abel <ra*******@gmail.com>
wrote:

On 2006-03-19, Herbert Rosenau <os****@pc-rosenau.de> wrote:

On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre
<ma**********@spamcop.net> wrote:

> On Sun, 19 Mar 2006 08:54:20 +0000 (UTC), in comp.lang.c , "Herbert
> Rosenau" <os****@pc-rosenau.de> wrote:
>
> > (<any cast>) malloc() results in
> >undefined behavor, p=malloc() is the only secure call allowed in C.
>
> Rubbish. Inserting a cast before malloc is not needed, but doesn't
> result in UB.

You should program under an environment that would use for return
valuses of different types different locations and then use casting on
functions returning other than int, forgetting to #include stdlib you
gets undefined behavior

The undefined behavior is not caused by the cast, and would happen
without it.

So far so right - but it will hide the diagnostic that would at least
help to fix the problem,

Of course. Nobody has denied this. What has been said all along is that
the cast _hides_, but does not itself _cause_, undefined behaviour.

Richard

[Arndt Jonasson]

CBFalconer <cb********@yahoo.com> writes:

Herbert Rosenau wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

... snip ...

Yes, since otherwise you won't be alerted by the compiler if you
fail to #include <stdlib.h>.

Liar! Never ever cast the return value of a function returning
void* - except you likes to land in the world of undefined behavior.

You are apparently trying to take over Dan Pops place in the
pantheon of diplomatic c.l.c posters. Calling someone a liar is
not going to get you very far. This is possibly a language barrier
problem (which Dan never had). Maybe you meant to say "false" or
"not so" or even "I disagree" etc.

Possibly he wants to indicate that Vladimir is lying not to the
audience, but to the compiler. But if so, that could be better put.

[Vladimir S. Oka]

Arndt Jonasson opined:

CBFalconer <cb********@yahoo.com> writes:

Herbert Rosenau wrote:

> "Vladimir S. Oka" <no****@btopenworld.com> wrote:
>

... snip ...

>>
>> Yes, since otherwise you won't be alerted by the compiler if you
>> fail to #include <stdlib.h>.
>
> Liar! Never ever cast the return value of a function returning
> void* - except you likes to land in the world of undefined
> behavior.

You are apparently trying to take over Dan Pops place in the
pantheon of diplomatic c.l.c posters. Calling someone a liar is
not going to get you very far. This is possibly a language barrier
problem (which Dan never had). Maybe you meant to say "false" or
"not so" or even "I disagree" etc.

Possibly he wants to indicate that Vladimir is lying not to the
audience, but to the compiler. But if so, that could be better put.

Quite possibly. For some reason the disagreement continued long after I
have admitted to mistyping "yes" for "no" in the quote above (that
should also have been clear from the rest of the post, now snipped).
See elsethread...

--
BR, Vladimir

Don't I know you?

[Jordan Abel]

On 2006-03-20, Vladimir S. Oka <no****@btopenworld.com> wrote:

Arndt Jonasson opined:

CBFalconer <cb********@yahoo.com> writes:

Herbert Rosenau wrote:
> "Vladimir S. Oka" <no****@btopenworld.com> wrote:
>
... snip ...
>>
>> Yes, since otherwise you won't be alerted by the compiler if you
>> fail to #include <stdlib.h>.
>
> Liar! Never ever cast the return value of a function returning
> void* - except you likes to land in the world of undefined
> behavior.

You are apparently trying to take over Dan Pops place in the
pantheon of diplomatic c.l.c posters. Calling someone a liar is
not going to get you very far. This is possibly a language barrier
problem (which Dan never had). Maybe you meant to say "false" or
"not so" or even "I disagree" etc.
Possibly he wants to indicate that Vladimir is lying not to the
audience, but to the compiler. But if so, that could be better put.

Quite possibly. For some reason the disagreement continued long after I
have admitted to mistyping "yes" for "no" in the quote above (that
should also have been clear from the rest of the post, now snipped).

The only other place in the rest of the post that would have clarified
was one word off from confirming the 'yes' and, since it was
sequentially later than the 'yes', was easily misread.
See elsethread...

[Mark McIntyre]

On Sun, 19 Mar 2006 21:03:36 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On Sun, 19 Mar 2006 14:49:17 +0100, in comp.lang.c , "Richard G.
Riley" <rg****@gmail.com> wrote:

in this case I would
ask you HOW you intend malloc to return different memory banks for
different types considering you cant tell malloc what it is malloc'ing
for.

You might want to read up on how early Motorola chips worked, before
sounding off...

Richard's error, I think, was in assuming we were talking about
different calls to malloc() returning their results in different
registers. Reading about the M68K wouldn't clear that up.

No, but it might prove instructive nevertheless!
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Vladimir S. Oka]

Jordan Abel opined:

On 2006-03-20, Vladimir S. Oka <no****@btopenworld.com> wrote:

Arndt Jonasson opined:

CBFalconer <cb********@yahoo.com> writes:
Herbert Rosenau wrote:
> "Vladimir S. Oka" <no****@btopenworld.com> wrote:
>
... snip ...
>>
>> Yes, since otherwise you won't be alerted by the compiler if
>> you fail to #include <stdlib.h>.
>
> Liar! Never ever cast the return value of a function returning
> void* - except you likes to land in the world of undefined
> behavior.

You are apparently trying to take over Dan Pops place in the
pantheon of diplomatic c.l.c posters. Calling someone a liar is
not going to get you very far. This is possibly a language
barrier
problem (which Dan never had). Maybe you meant to say "false" or
"not so" or even "I disagree" etc.

Possibly he wants to indicate that Vladimir is lying not to the
audience, but to the compiler. But if so, that could be better put.

Quite possibly. For some reason the disagreement continued long
after I have admitted to mistyping "yes" for "no" in the quote above
(that should also have been clear from the rest of the post, now
snipped).

The only other place in the rest of the post that would have
clarified was one word off from confirming the 'yes' and, since it
was sequentially later than the 'yes', was easily misread.

Yes, yes, yes. I do admit that my original post was messed up. My
subsequent ones were (I hope) quite clear, but that didn't seem to be
good enough.

I'll drop it here.

--
BR, Vladimir

Newton's Fourth Law: Every action has an equal and opposite
satisfaction.

[CBFalconer]

"Vladimir S. Oka" wrote:

Jordan Abel opined:

.... snip ...

The only other place in the rest of the post that would have
clarified was one word off from confirming the 'yes' and, since
it was sequentially later than the 'yes', was easily misread.

Yes, yes, yes. I do admit that my original post was messed up.
My subsequent ones were (I hope) quite clear, but that didn't
seem to be good enough.

I'll drop it here.

Not a chance with this crowd. They have their teeth sunk into you,
and will worry this nonsense into the ground and back several times
before letting it die.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Herbert Rosenau]

On Sun, 19 Mar 2006 21:47:23 UTC, "Vladimir S. Oka"
<no****@btopenworld.com> wrote:

Herbert Rosenau opined:

On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka"
<no****@btopenworld.com> wrote:

[snip]
OK, I think where the disconnect is.

We both agree that casting the return from `malloc()` is a Bad Thing.

Where we seem to disagree seems to be where the UB comes from if
<stdlib.h> is not included.
No.
You seem to think it's the cast that does it.
No, the cast hides the error and the diagnostic threout.
I, OTH, think that UB has already happened *before*, and independently
of the cast. Cast may just hide the diagnostic that may have warned
you of the problem. (FWIW, it does seem that a few other people here
share my view.)

< big snip >

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Vladimir S. Oka]

Herbert Rosenau opined:

On Sun, 19 Mar 2006 21:47:23 UTC, "Vladimir S. Oka"
<no****@btopenworld.com> wrote:

Herbert Rosenau opined:

> On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka"
> <no****@btopenworld.com> wrote:

[snip]

OK, I think where the disconnect is.

We both agree that casting the return from `malloc()` is a Bad
Thing.

Where we seem to disagree seems to be where the UB comes from if
<stdlib.h> is not included.

No.

You seem to think it's the cast that does it.

No, the cast hides the error and the diagnostic threout.

OK. You win.

--
BR, Vladimir

This MUST be a good party -- My RIB CAGE is being painfully pressed up
against someone's MARTINI!!

[Keith Thompson]

"Vladimir S. Oka" <no****@btopenworld.com> writes:

Herbert Rosenau opined:

On Sun, 19 Mar 2006 21:47:23 UTC, "Vladimir S. Oka"
<no****@btopenworld.com> wrote:

Herbert Rosenau opined:

> On Sun, 19 Mar 2006 13:00:22 UTC, "Vladimir S. Oka"
> <no****@btopenworld.com> wrote:

[snip]

OK, I think where the disconnect is.

We both agree that casting the return from `malloc()` is a Bad
Thing.

Where we seem to disagree seems to be where the UB comes from if
<stdlib.h> is not included.

No.

You seem to think it's the cast that does it.

No, the cast hides the error and the diagnostic threout.

OK. You win.

In what sense does he "win"? He clearly said previously that the cast
causes undefined behavior. Now he's changed is story, but without
acknowleding his error.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[CBFalconer]

Keith Thompson wrote:

"Vladimir S. Oka" <no****@btopenworld.com> writes:

Herbert Rosenau opined:
.... snip ...

No, the cast hides the error and the diagnostic threout.

OK. You win.

In what sense does he "win"? He clearly said previously that
the cast causes undefined behavior. Now he's changed is story,
but without acknowleding his error.

I interpret Vladimirs posting as "I'm tired of this pointless
argument".

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR

[Vladimir S. Oka]

CBFalconer opined:

Keith Thompson wrote:

"Vladimir S. Oka" <no****@btopenworld.com> writes:

Herbert Rosenau opined:
... snip ...
No, the cast hides the error and the diagnostic threout.

OK. You win.

In what sense does he "win"? He clearly said previously that
the cast causes undefined behavior. Now he's changed is story,
but without acknowleding his error.

I interpret Vladimirs posting as "I'm tired of this pointless
argument".

Exactly.

This abominable thread already had my head spinning from trying to
figure out what /is/ his POV after all.

[I also suspect he changed his mind but wwouldn't admit to it.]

--
BR, Vladimir

There was a young man of Ostend
Who let a girl play with his end.
She took hold of Rover,
And felt it all over,
And it did what she didn't intend.