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

[CBFalconer]

Thunderbird wrote:
.... snip ...


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

 

[santosh]

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]

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.

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:

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.

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.

 

[P.J. Plauger]

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.

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]

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

 

[Herbert Rosenau]

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.

variadic functions?
Mark McIntyre

--
Tschau/Bye
Herbert

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

 

[CBFalconer]

.... snip ...

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.

--
"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/>

 

[Vladimir S. Oka]

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

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

 

[Mark McIntyre]

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.

At the risk of repeating myself, variadic functions?
Mark McIntyre

 

[Mark McIntyre]

Herbert Rosenau opined:


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.

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

 

[Richard G. Riley]

You should program under an environment that would use for return
valuses of different types different locations and then use casting

on

This was a discussion of some merriment a while ago. Sometimes things
are made a little too clever for their own good : 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.

 

[Richard Tobin]

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.

-- Richard

 

[Keith Thompson]

on

This was a discussion of some merriment a while ago. Sometimes things
are made a little too clever for their own good : 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.

malloc() returns a result of type void*. Presumably it always returns
that result in the same way, but it could return it in, say, an
address register. A function *other than malloc()* could return its
result in, say, a data register rather than an address register.
Calling malloc() with no visible prototype (at least in C90) causes
the compiler to assume that malloc() returns int, and therefore that
its result will be in a different register than the one malloc()
actually uses.

 

[Keith Thompson]

On Fri, 17 Mar 2006 18:44:03 UTC, "Vladimir S. Oka"


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

Vladimir accidentally typed "Yes" when he clearly meant "No". This
has already been pointed out and acknowledged. Possibly you didn't
see that, but it should have been obvious from the rest of what he
wrote.

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

Nonsense. Calling malloc() with no prototype in scope causes
undefined behavior (at least in C90). Applying a correct cast does
not make the behavior any more or less defined.

For example, the following:

#include <stdlib.h>
int main(void)
{
int *ptr = (int*)malloc(sizeof(int));
return 0;
}

is perfectly valid; the cast is unnecessary, but harmless. (The cast
is harmful if it converts the result to the wrong type, or if it masks
a failure to include <stdlib.h>, or if it masks a failure to use a C
compiler rather than a C++ compiler. All these can be easy mistakes
to make, which is why we strongly discourage casting the result of
malloc().)

And a very few people have valid reasons to write code that will
compile as both C and C++; for them, the cast (done carefully) is
mandatory.

However, I'm going to assume that this was an honest mistake on your
part. I'm going to resist the temptation to call you a liar, with or
without an exclamation point.

Conceivably this is a language problem. To be clear, by using the
word "liar", you are accusing Vladimir of deliberately, maliciously,
and knowingly making false statements. This is extraordinarily rude
on your part, as well as being wrong.

You owe Vladimir (and the rest of us) an apology.

 

[Jordan Abel]

Herbert Rosenau opined:


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.

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

Now you're skating on thin ice with your choice of words!

Your wording was awkward - it's easy to skim over the extra "not", and
think you said "casting is not required, but good sense". In combination
with the "yes" from before, it's even easier to miss.

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


I submit that:

#include <stdio.h>

...

puts("Hello, world!");

is safe as well.

I think he meant the only secure call _to malloc_

Maybe, but how does this relate to:

"unspecified value" nothing - calling a function that returns void * as
if it were a function returning int is flat-out undefined behavior. Say
that a given implementation returns on the stack, and the extra space
overwritten by the [larger] void * overwrites something important, like
half of a return address.

 

[Jordan Abel]

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.

Also, people who can only think of an implementation using different
registers for pointers, or having larger pointers and so having half the
pointer chopped off, have no imagination. What if the register that's
used for returning pointers in functions that do so is supposed to be
saved by the callee in other functions, and was being used by the caller
for something important? If only part of the pointer representation fits
in the "int return register", where does the other half go? It has to go
somewhere, and since the caller isn't expecting anything in wherever
that somewhere is, serious problems could happen.

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.

 

[Jordan Abel]

on

This was a discussion of some merriment a while ago. Sometimes things
are made a little too clever for their own good : 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.

No... he's talking about the implementation of function calls using a
different location for return VALUES [i.e. the pointer or int itself] of
different types, not anything about the implementation of malloc.

(unless you're thinking of the floating-point-memory discussion. that
was fun. the implementation of struct layouts that someone came up with
was VERY convoluted)

 

[Jordan Abel]

Vladimir accidentally typed "Yes" when he clearly meant "No". This
has already been pointed out and acknowledged. Possibly you didn't
see that, but it should have been obvious from the rest of what he
wrote.


Nonsense. Calling malloc() with no prototype in scope causes
undefined behavior (at least in C90). Applying a correct cast does
not make the behavior any more or less defined.

For example, the following:

#include <stdlib.h>
int main(void)
{
int *ptr = (int*)malloc(sizeof(int));
return 0;
}

is perfectly valid; the cast is unnecessary, but harmless. (The cast
is harmful if it converts the result to the wrong type, or if it masks
a failure to include <stdlib.h>, or if it masks a failure to use a C
compiler rather than a C++ compiler.

Though, use of a C++ compiler could be by design. Didn't K&R verify
their code for the second edition using a C++ compiler, since there
weren't any 'proto-ansi' C compilers in existence yet?

"It's a subset of C++ now and will be a subset of C once C catches up",
basically.

 

[Richard Tobin]

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

[/QUOTE]

variadic functions?

Pedantically, there is never a *need* for a cast of void *, since you
could instead assign it to a variable of the right type and use that.
But there are plenty of cases where a cast is natural, such as in
simple comparison functions for qsort(), for example:

static int int_compare(const void *a, const void *b)
{
return *(int *)a - *(int *) b;
}

-- Richard