why is casting malloc a bad thing?

[E. Robert Tisdale]

I will be perfectly willing (as my posting history shows)
to accept that I'm wrong
if it can be shown that I am in fact wrong.
So far, however, you have not shown me to be wrong.

You can lead a mule to water but you can't make him drink.

 

[Sidney Cadot]

If that's a tee-shirt slogan, it simply proves my point.

Stack overflow - core dumped

Best regards,
Sidney

 

[Mark McIntyre]

If you write malloc calls without casts, it's not because it's
necessarily good programming practice but because your grandfather did.

You know, normally I quite respect you, you're a damn fine programmer
and so forth.

But this is the one place where you're an idiot. A complete one.

 

[Mark McIntyre]

Next step after nonsense -- bullshit. See 6.3.2.3, para. 7.

Next step after bullshit - irrelevancy. See 6.3.2.3 para 1.

You might also want to consider that void* is not a pointer to either
an incomplete type, or an object.

 

[Jeremy Yallop]

You might also want to consider that void* is not a pointer to either
an incomplete type, or an object.

There are three kinds of type in C: object types, function types and
incomplete types. "void" is an incomplete type.

"The void type comprises an empty set of values; it is an incomplete
type that cannot be completed."

Jeremy.

 

[P.J. Plauger]

You know, normally I quite respect you, you're a damn fine programmer
and so forth.

But this is the one place where you're an idiot. A complete one.

Thanks very much -- completeness is so hard to achieve in any endeavor
in these complex times.

What I find interesting about this debate is the two positions being
espoused:

1) Omitting casts on malloc calls is acceptable, but not necessarily
virtuous.

2) Putting casts on malloc calls is stupid.

Those of us in the first camp are going to keep using casts, and we're
going to keep respecting those who don't. It would be nice if we were
granted a bit of respect in turn, but what the hell. A closed mind
avoids the risk of having to change.

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

 

[E. Robert Tisdale]

You know, normally I quite respect you,
you're a damn fine programmer and so forth.

But this is the one place where you're an idiot. A complete one.

That's an 'Ad Hominen' argument:

http://www.don-lindsay-archive.org/skeptic/arguments.html#hominem

Whether P. J. Plauger is complete or incomplete idiot
has no bearing upon whether he is correct or not.

Stupid people use fallacious arguments to persuade other stupid people.
Your personal attack on P. J. Plauger is a clear signal
to all subscribers that you have lost your argument
and descended to name calling instead of withdrawing graciously.

 

[Allin Cottrell]

That's an 'Ad Hominen' argument...

It may be cheeky, but it's obviously _not_ an argument ad hominem.
McIntyre does not at all "deduce" the falsity of Plauger's views
on casting the return from malloc from Plauger's (supposed) idiocy.

Allin Cottrell

 

[Richard Heathfield]

You can lead a mule to water but you can't make him drink.

You can attempt to substitute slogans for thought, but you can't convince
comp.lang.c that way.

 

[Richard Heathfield]

You know, normally I quite respect you, you're a damn fine programmer
and so forth.

But this is the one place where you're an idiot. A complete one.

If you're wise, Mark, you'll retract that. Mr Plauger's statement, quoted
above, is IMHO erroneous, but I don't think it's legitimate to call him an
idiot.

He has already stated for the benefit of this newsgroup that (what I
consider to be) his unusual circumstances make it sensible for him to make
his code capable of being compiled under both C and C++; given his
reputation, it makes sense to take him at his word (although that does not
necessarily mean it's sensible to emulate him blindly, in this case; we're
not /all/ writing standard libraries for C and C++ compilers, after all).

I am not forced into the position of choosing which of you is right about
malloc (for I have my own opinion on that, and I like to think that it's an
informed opinion); and thank heaven for that, when both sides are using
words like "idiot" and "nonsense". I dread to think what must be going
through the newbies' heads as they read your exchange with Mr Plauger.

 

[E. Robert Tisdale]

If you're wise, Mark, you'll retract that.
Mr. Plauger's statement, quoted above, is IMHO erroneous
but I don't think it's legitimate to call him an idiot.

He has already stated for the benefit of this newsgroup that
(what I consider to be) his unusual circumstances
make it sensible for him to make his code capable
of being compiled under both C and C++; given his reputation,

Please note that P. J. Plauger *never* "pulled rank" on you.
As far as I'm concerned Mr. Plauger is just another subscriber
to the comp.lang.c newsgroup. I find his argument compelling
because it is sound and *not* because of his "reputation".

it makes sense to take him at his word
(although that does not necessarily mean that it's sensible
to emulate him blindly, in this case; we're not /all/
writing standard libraries for C and C++ compilers, after all).

I don't think that
Mr. Plauuger ever argued hardship or special circumstances.

I am not forced into the position of choosing
which of you is right about malloc (for I have my own opinion on that,
and I like to think that it's an informed opinion);
and thank heaven for that,
when both sides are using words like "idiot" and "nonsense".
I dread to think what must be going through the newbies' heads
as they read your exchange with Mr Plauger.

New subscribers should note that style issues
are the most contentious issues argued in the comp.lang.c newsgroup.

 

[Christian Bau]

That's an 'Ad Hominen' argument:

http://www.don-lindsay-archive.org/skeptic/arguments.html#hominem

Whether P. J. Plauger is complete or incomplete idiot
has no bearing upon whether he is correct or not.

Stupid people use fallacious arguments to persuade other stupid people.
Your personal attack on P. J. Plauger is a clear signal
to all subscribers that you have lost your argument
and descended to name calling instead of withdrawing graciously.

Tisdale, you shouldn't get involved in a discussion between adults, even
when these adults don't behave as if they are adults.

Considering your history of trolling, forging posts, giving ridiculous
advice to newcomers, any moral judgment coming from you is deeply
unappreciated.

 

[Papadopoulos Giannis]

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

thanks,

Brian Blais

I' ve read nearly completely the whole thread, although in the way I
lost my path.

I assume the following:

d = malloc(50*sizeof(*d));
--------------------------
o the sortest way
o the most portable
o does remember you to include stdlib
o changing type of d does not affect anything
o it looks a bit funny

d = malloc(50*sizeof(double));
------------------------------
o changing type of d is disastrous

d = (double*)malloc( 50*sizeof(double) );
-----------------------------------------
o does not want stdlib (but aren't all pointers unsigned ints? - enlight
me plz)
o it gives a good hint on what d's type is
ï if you change d's type it tells you so

Am I missing anything else???

 

[E. Robert Tisdale]

Papadopoulos Giannis wrote:

I' ve read nearly completely the whole thread
although in the way I lost my path.

I assume the following:

d = malloc(50*sizeof(*d));

No. It does *not* remind you to include stdlib.
The best that you can expect is that your compiler
will issue a diagnostic:

warning: implicit declaration of function `malloc'

o changing type of d does not affect anything
o it looks a bit funny

d = malloc(50*sizeof(double));

A good C compiler will tell you that

warning: implicit declaration of function `malloc'

(but aren't all pointers unsigned ints? - enlight me plz)
No.

o it gives a good hint on what d's type is

So would

double* d = (double*)malloc(50*sizeof(double));

 

[Papadopoulos Giannis]

So???



So would

double* d = (double*)malloc(50*sizeof(double));

I think I wrote it first - though, without the leading double* which
is implied indeed...

 

[Richard Bos]

[ Imprimis, while snipping is good, snipping every single bit of context
is not. ]

Stroutstrup himself has said that all good-style C programs are also C++
programs,

Well, he's just wrong, then, isn't he? Or rather, he has what I would
consider silly opinions about what is good style in C; good style in C
does _not_ involve useless casts strewn through your code.

so it's just better style.

Let me get this right: someone who is an authority on C++ says something
about C, _so_ it is correct? Don't you think you trust big names a bit
too easily?

Also, we're not limited to malloc() here,

One more reason not to care what a C++ compiler does with C code.

Thirdly, it's always best to be explicit.

Wrong.

Or do you also write

(void) (int_a = (int) int_b);

and

for (i=(size_t)0;
(size_t)i<(size_t)NUMENTRIES;
i=(size_t)((size_t)i+(size_t)1))
if ((int)mung_array((int *)array, (size_t)i)!=(int)0)
break;

Lastly, it provides compatibility with older compilers.

Which, for the average user, is the only reason, and it is one that
should come up rarely, if ever.

OTOH, too many casts engender confusion in the programmer and insecurity
in the maintainer, so they are an abomination.

Richard

 

[Joona I Palaste]

I' ve read nearly completely the whole thread, although in the way I
lost my path.

I assume the following:

d = malloc(50*sizeof(*d));

Well, the shortest way would be d = malloc(50*sizeof *d), but you're
otherwise right.

o the most portable
o does remember you to include stdlib
o changing type of d does not affect anything
Yes.

o it looks a bit funny

That's a matter of taste.

d = malloc(50*sizeof(double));
------------------------------
o changing type of d is disastrous
Right.

d = (double*)malloc( 50*sizeof(double) );

This is not true at all. Pointers and unsigned ints are entirely
different beasts. They aren't even required to have the same size!
And even if they have the same size, they might be coming from
different places, for example different data transfer registers.
Note that casting the return value of malloc() *ONLY* shuts up
compiler warnings. It *DOES NOT* fix the code.
Read carefully, because this is important:
*** THE - CODE - IS - STILL - BROKEN!!! ***

o it gives a good hint on what d's type is
ï if you change d's type it tells you so

True, but as the code is broken anyway, this is irrelevant.

Am I missing anything else???

No, that's basically it.

 

[Christian Bau]

Am I missing anything else???

The only thing that is missing is that many good programmers try to
avoid any unnecessary cast if at all possible:

A cast tells the compiler "Shut up, I know what I am doing". In reality
it means "Shut up, I thought I knew what I was doing when I wrote this,
even though I might have been wrong at the time or things might have
changed and nowadays the code might be completely wrong".

For example, your program might contain an extern function

int nalloc (double x);

Maybe not very clever to have a function with a name very similar to
malloc, but you might have a completely good reason to use that function
name. Suppose this function does something completely different than
malloc, and suppose you type the malloc call wrong:

double* d = nalloc (100 * sizeof (double)); // Error
double* d = (double *) nalloc (100 * sizeof (double)); // No error

So many people have the habit of _never_ using casts if they can be
avoided.

 

[Christian Bau]

OTOH, too many casts engender confusion in the programmer and insecurity
in the maintainer, so they are an abomination.

Usually goes like this:

"This cast looks useless to me. No good programmer would use useless
casts. I assume that the original author was a good programmer, so he
wouldn't use useless casts, so the cast is not useless. So what is this
damned cast doing that I cannot figure out? "

And now we have a maintenance programmer wasting time to figure out what
a useless cast is good for, because he made the (incorrect) assumption
that the author knew what he was doing...

 

[Papadopoulos Giannis]

This is not true at all. Pointers and unsigned ints are entirely
different beasts. They aren't even required to have the same size!
And even if they have the same size, they might be coming from
different places, for example different data transfer registers.
Note that casting the return value of malloc() *ONLY* shuts up
compiler warnings. It *DOES NOT* fix the code.
Read carefully, because this is important:
*** THE - CODE - IS - STILL - BROKEN!!! ***

I got confused by the older C spec... Sorry...

As for the

d = (double*)malloc( 50*sizeof(double) );

d is double*...


But if I want to make illegal actions, casting is the best...

Tnx anyway