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\ngoo d");
else printf("\n\nfai l");

free(p);
if(!p) printf("\n\ngoo d");
else printf("\n\nfai l");

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

the result is:

fail

good

fail

100

why?

[CBFalconer]

santosh wrote:

Thunderbird wrote:
.... snip ...

is there any difference in standard c between "p=(char
*)malloc(1000)" and "p=malloc(1000) "?

p = malloc( 1000 * sizeof (char) ) is a better form than both the
above.

No it isn't. sizeof(char) is always 1. If you do want to make
things track the type of p properly, write:

p = malloc(1000 * sizeof *p);

--
"If you want to post a followup via groups.google.c om, 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/googlegroupsrep ly/>

[santosh]

CBFalconer wrote:

santosh wrote:

Thunderbird wrote:

... snip ...

is there any difference in standard c between "p=(char
*)malloc(1000)" and "p=malloc(1000) "?

p = malloc( 1000 * sizeof (char) ) is a better form than both the
above.

No it isn't. sizeof(char) is always 1. If you do want to make
things track the type of p properly, write:

p = malloc(1000 * sizeof *p);

Thanks for the correction.

[Herbert Rosenau]

On Fri, 17 Mar 2006 18:44:03 UTC, "Vladimir S. Oka"
<no****@btopenw orld.com> wrote:

No, malloc returns void *, not void; and it requires no cast in C.
K&R, for some strange reason, decided to test their code using a C++
compiler. In C++, the cast is required. In C, it is not. (But in C++,
you almost certainly won't be using malloc anyway.)

now there is another thing i wanna know.should i cast malloc when i
call malloc() in standard c?

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.

is there any difference in standard c between "p=(char
*)malloc(1000)" and "p=malloc(1000) "?

Functionally, no, but see previous comment (i.e. not casting is not
required, but good sense).

Liar! There IS a mayor difference (<any cast>) malloc() results in
undefined behavor, p=malloc() is the only secure call allowed in C.

There are implementations using different places for different return
types, so casting results in getting some unspecified value converted
to some undefined value -> undefined behavior.

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

True, some diagnostic may show not clearly what you expects but what
the compiler sees. casting is in absolute way never ever a solution to
get an diagnostic away.

You should cast only if you are absoltely knows what <ou're doing.
cast only to get a diagnostic away is always and under any
circumstance lying to the compiler and the compiler will revange for
that lie in any way it likes.

--
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 Fri, 17 Mar 2006 18:44:03 UTC, "Vladimir S. Oka"
<no****@btopenw orld.com> wrote:

>> No, malloc returns void *, not void; and it requires no cast in
>> C. K&R, for some strange reason, decided to test their code using
>> a C++ compiler. In C++, the cast is required. In C, it is not.
>> (But in C++, you almost certainly won't be using malloc anyway.)
>
> now there is another thing i wanna know.should i cast malloc when
> i call malloc() in standard c?
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.

I do not particularly care being called a liar, especially followed by
an exclamation mark, but I'll give you a benefit of a doubt...

Yes, I have mistyped "yes" for "no", which Richard kindly pointed out
in elsethread, and I have acknowledged that.

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.

> is there any difference in standard c between "p=(char
> *)malloc(1000)" and "p=malloc(1000) "?

Functionally, no, but see previous comment (i.e. not casting is not
required, but good sense).

Liar!

Now you're skating on thin ice with your choice of words!
There IS a mayor difference (<any cast>) malloc() results in
undefined behavor
Care to elaborate on how exactly my answer to the OP's question is
factually wrong. I advise you again to read the OP, where casting from
`void *` to `char *` (or some other pointer type) is discussed, not
casting to, say, `double`.
p=malloc() is the only secure call allowed in C.
I submit that:

#include <stdio.h>

...

puts("Hello, world!");

is safe as well.
There are implementations using different places for different return
types,
Maybe, but how does this relate to:
so casting results in getting some unspecified value converted
to some undefined value -> undefined behavior.
I'm a bit confused by this, but I think I see where you're aiming at.
There is under absolutely no circomstance a need for a cast of
(void*) to anything else.
We seem to agree on this, making me wonder what your post was really
about...
True, some diagnostic may show not clearly what you expects but what
the compiler sees. casting is in absolute way never ever a solution
to get an diagnostic away.
Yes, that was my reply to the OP as well (in slightly less strong
terms).
You should cast only if you are absoltely knows what <ou're doing.
cast only to get a diagnostic away is always and under any
circumstance lying to the compiler and the compiler will revange for
that lie in any way it likes.

Again, yes, but IMHO beside the point.

--
BR, Vladimir

It's possible that the whole purpose of your life is to serve
as a warning to others.

[P.J. Plauger]

"Herbert Rosenau" <os****@pc-rosenau.de> wrote in message
news:wm******** *************** ****@URANUS1.DV-ROSENAU.DE...

On Fri, 17 Mar 2006 18:44:03 UTC, "Vladimir S. Oka"
<no****@btopenw orld.com> wrote:

>> No, malloc returns void *, not void; and it requires no cast in C.
>> K&R, for some strange reason, decided to test their code using a C++
>> compiler. In C++, the cast is required. In C, it is not. (But in C++,
>> you almost certainly won't be using malloc anyway.)
>
> now there is another thing i wanna know.should i cast malloc when i
> call malloc() in standard c?

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.

Why do you even *imagine* that someone would lie about a thing
so unimportant as this? Besides, it's extremely bad manners to
accuse someone of lying in this forum. Besides, you're wrong.

> is there any difference in standard c between "p=(char
> *)malloc(1000)" and "p=malloc(1000) "?

Functionally, no, but see previous comment (i.e. not casting is not
required, but good sense).

Liar! There IS a mayor difference (<any cast>) malloc() results in
undefined behavor, p=malloc() is the only secure call allowed in C.

You just did it again. And you were factually wrong again. Couth up.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Mark McIntyre]

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.
There is under absolutely no circomstance a need for a cast of (void*)
to anything else.

variadic functions?
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

[Herbert Rosenau]

On Sun, 19 Mar 2006 11:27:39 UTC, Mark McIntyre
<ma**********@s pamcop.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 - find then all that will cost you more time
as to write one million lines of conforming code. It is m ore than
important only using a cast when you 10000000% exactly sure that you
knows what you does or you will deliver extremly bad programs who may
cost not only damage but human live - only because you are too dumb to
see that making casts where you must lie to the compiler only to get
an diagnosting away instead to follow the rules tho says never use a
cast when you're not clearly and absolutely sure that it isd needed to
become what you would but not only to get diagnostics away.

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

variadic functions?
Mark McIntyre

--
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 11:27:39 UTC, Mark McIntyre
<ma**********@s pamcop.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)?
forgetting to #include stdlib you gets undefined behavior
And why it would lead to this?
- find then all that will cost you more
time as to write one million lines of conforming code.
Are you now proposing writing non-conforming code?
It is m ore
than important only using a cast when you 10000000% exactly sure that
you knows what you does or you will deliver extremly bad programs
I can agree with this.
who
may cost not only damage but human live - only because you are too
dumb to see that making casts where you must lie to the compiler only
to get an diagnosting away instead to follow the rules tho says never
use a cast when you're not clearly and absolutely sure that it isd
needed to become what you would but not only to get diagnostics away.

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

--
BR, Vladimir

Do not overtax your powers.

[Mark McIntyre]

On Sun, 19 Mar 2006 12:33:52 +0000 (UTC), in comp.lang.c , "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

I've programmed for these, they're a classic reason why you must
include stdlib.h. Its nothing to do with casting tho.
and then use casting on
functions returning other than int, forgetting to #include stdlib you
gets undefined behavior

This has nothing to do with casting malloc, its entirely to do with
returing ints and pointers in different registers.

The cast masks the error, it doesn't cause it. Don't let yourself get
confused by cause and effect.

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

At the risk of repeating myself, variadic functions?
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

[Mark McIntyre]

On Sun, 19 Mar 2006 13:00:22 +0000 (UTC), in comp.lang.c , "Vladimir
S. Oka" <no****@btopenw orld.com> wrote:

Herbert Rosenau opined:

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

On the h/w in question, pointers are returned (say) in the A1register,
and ints in the B1 register.

Failure to include stdlib.h causes the compiler to think malloc
returns an int, and emit code to read from B1. The real pointer is of
course in A1, so any attempt to write through the pointer will cause a
crash.

forgetting to #include stdlib you gets undefined behavior

And why it would lead to this?

See above. The compiler does of course complain about the incompatible
returns, and novice or C++ programmers insert a cast to silence it.

I agree with you tho, the UB is nothing to do with the cast, its to do
with not properly declaring malloc. The same would apply to any
function returning a pointer on this h/w. If stdlib had been included,
the code, with or without cast, would have been well defined.
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