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

[Mark McIntyre]

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

Mark McIntyre

 

[Richard Tobin]

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.

[/QUOTE]

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

Yes, but that relates to different functions (returning pointers or
integers) rather than - as Riley misinterpreted - a function returning
memory to be used for different types. A function of given return
type always returned in the same register.

(Has so much time really passed that 68000s are "early Motorola
chips"?)

-- Richard

 

[Keith Thompson]

For example, the following:
[snip]

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?

Yes, that's true, and I explicitly acknowledged in a paragraph that
you snipped that there can be valid reasons to compile C code with a
C++ compiler. (The use of a C++ compiler, I think is, why the
examples in K&R2 cast the result of malloc(); it's corrected in the
errata.)

 

[Keith Thompson]

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.

 

[Herbert Rosenau]

Herbert Rosenau opined:


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.

So there are implementations around where void* or char* will occupy
56 bits while int is only 48 bits. They have special registers for
storing pinters in, other to stor floatingpoint values and another to
store int pointers, having other instructions addressing pointers
other ones addressing floating point values, other for floatingpoint
and so on.

Getting an exception on addressing a pointer in int registers creates
an exception.

A void* can not been interpreted as int - whereas C defines that any
undefined function returns int. So casting that value requires some
special mashine instructs and will fail miserably becaus the 56 bits
returned by malloc gets lost completely while an random bitpattern
gets used for converting that to a pointer.

And why it would lead to this?

Because the differences between void* and int are significant and may
occre in something but not what you means you get.

Are you now proposing writing non-conforming code?

No, here we speak only about strictly conforming code.

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.

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.

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.

It looks like there is a need to drum into somebody that casting is
almost the wrongest method to resolve a problem.

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.

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.

--
Tschau/Bye
Herbert

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

 

[Herbert Rosenau]

At the risk of repeating myself, variadic functions?

I've had in 20 years of experience in C not a single time the need to
cast a void* to an variadic function (not even printf) because the
caller would never know what real type is sitting behind the void* -
but the callee knows that he gets a void* and will either been able to
use the data or is only a forwarder to a function that knows about the
real data.

void* is a nice method to hide information to data that is handled in
specific parts of the program but needs stored external of them
because the livetime of the data requires that. Information hiding
makes maintenance of big programs more secure.

--
Tschau/Bye
Herbert

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

 

[Herbert Rosenau]

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.

Really? Why does you need to tell malloc() which different type you
needs memory for?

Yes, there is a possibility to help malloc in organising its heap
better:
- a high frequency of dynamic to allocate memory in high
different size
- extremely high usage of dynamic memory because the mass
of data is nearly on the address space the underlying
OS is willing to give an single application.

Solution: Write your own replacement of malloc that maintains multiple
lists of different size groups. Anyway, malloc() has never a need to
know what type of date ist should give a chunk of memory for and so it
will return simply a void* pointing to the 1. byte of the memory it
has reserved in the given size.

--
Tschau/Bye
Herbert

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

 

[Herbert Rosenau]

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.

--
Tschau/Bye
Herbert

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

 

[Herbert Rosenau]

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.

I don't read always immediately all messages my server serves me and
sometimes my server likes to give me not all messages already written
and currently on some server prior it on the way to it. So when I read
a thread I can only read what is already inside my client. That means
I read a message and decide to answer or not before I switch to the
next one.

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

The cast is superflous and NOT harmell because it will hide any
diagnostic when the #include gets removed. Don't tell me that would
never occure. Such mistakes are easy done on the next review of the
code.

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.

There is no reason to send a call of malloc() through C++ compiler.
With that argument you should require that the stdlib has to be
compilant to pascal, Algol, Fortran, LISP and other languages too.


--
Tschau/Bye
Herbert

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

 

[Herbert Rosenau]

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.

--
Tschau/Bye
Herbert

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

 

[Herbert Rosenau]

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.

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]

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]

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:

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

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

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

 

[Stefan Krah]

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]

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]

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]

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:

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

 

[Jordan Abel]

Arndt Jonasson opined:


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.