why is casting malloc a bad thing?

[Christian Bau]

On the Nth hand, something like

p = malloc(sizeof *p);

is particularly handy, because you can change the type of p
without having to dive into the code everywhere. Better (IMO)
would be something like

p = (typeof *p)malloc(sizeof *p);

but I don't think that works.

If we go into things that are not C, then why not

allocate (p, 1);

with a new library function "allocate" which takes two arguments: An
lvalue p which must be a pointer to a complete type, and an integer. The
function would allocate space for as many objects as the integer
specifies and store the result in the pointer variable.

No chance to cast anything, so the whole argument would go away

(Even better if this comes together with a reallocate function that
returns a boolean upon success; using realloc is always a pain. )

 

[Ben Pfaff]

The universal solution, not approved by some style mavens, is to
remove the roll from the dispenser and leave it on the tank.
This makes it fairly easy to perform the necessary allocations.

This also avoids a potential problem wherein the roll resists
turning, thereby leading to excessive fragmentation ;-)

 

[Papadopoulos Giannis]

Then *why* do you use parantheses in return statements? To make return
look like a function, so you can snigger when newbies think it really
*is* a function? =)

Never thought of it... You are right... I started changing all my
sourcecode...

 

[P.J. Plauger]

1) Given that casts from malloc _are_ superfluous, why should one
cast?

Given that most whitespace _is_ superfluous, why should one use
whitespace?

(References to languages other than ISO C are off-topic for this
newsgroup
e.g., ``I do so because I program in C++ at work, so I have adopted this
habit''
-- what you do at work is really irrelevant for this newsgroup, i.e., ERT's
original post)

Ever think of becoming a defense lawyer? You certainly like to stack the
deck against any answers you don't want to hear.

Actually, I've given more than one answer to this question, in this and
recent threads, that I believe meets your requirement of admissibility.
But I weary of repeating myself still more. All I'm holding out for,
and all I've asked for from the beginning, is for people to recognize
that:

1) Style rules should be developed by considering all applicable
principles and weighing their various importance *for that particular
rule*.

2) Well meaning people can have good reasons for giving different
weights and hence coming up with different style rules.

2) Why should one cast from malloc when it might suppress a warning
which might otherwise be useful? (We all forget to include headers from
time to time)

I've discussed this before, with my personal weights, too.

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

 

[Mark McIntyre]

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

Correct. But not these two. The two positions are

1) putting in malloc casts is perfectly ok, its harmless.
2) putting in malloc casts is unnecessary and therefore not ok.

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

2) Putting casts on malloc calls is stupid.

If you were in either camp, I'd rescind my remark faster than a very
fast thing on roller skates, being towed by a jag.

Those of us in the first camp are going to keep using casts,

But you're not in that camp. Youre in the "casting malloc is a good
thing" camp, as your own postings both in this thread and elsewhere
have showed.

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.

As I said, I respect you enormously. You mistake intolerance of your
one stupidity for lack of respect

A closed mind avoids the risk of having to change.

I'd not know, I don't have one.

 

[Mark McIntyre]

So???

So don't assume they are, or your programme will crash.

I think I wrote it first

I suspect that D Ritchie has that honour

- though, without the leading double* which
is implied indeed...

At the risk of concealing a missed header, and making the code hard to
read. IMHO, YMMV.

 

[Default User]

Given that most whitespace _is_ superfluous, why should one use
whitespace?

How are casts from malloc() superfluous? Code should work identically
whether the casts are there or not. However, code that uses casts is
different from that which does not in cases of failure to properly
declare malloc(). In that case they convert a int into a pointer.



Brian Rodenborn

 

[Mark McIntyre]

Not in that sentence. It's a bald statement that happens to be untrue.
Now, had he said "there is no such thing aa an invalid conversion from
malloc(sizeof(double) to double*" I'd be quick to agree. But he didn't.
And precision is everything in our business.

IF you'd been following the context, it would have been abundantly
clear. But I guess we all snipped too much context.

 

[Mark McIntyre]

Given that most whitespace _is_ superfluous, why should one use
whitespace?

Igenerallydon'twhenitdoesn'tmatter-haveyoueverseenwebbytheway?

Joking aside, you're actually reinforcing one of the arguments against
casting. One should write for readability. Whitespace (used
approriately) improves that. Casts (used appropriately) improve that.
Casts stuck in where unnecessary do not improve that.

Ever think of becoming a defense lawyer? You certainly like to stack the
deck against any answers you don't want to hear.

This statement has a fine legal name, which escapes me for the moment.
Its something to do with trying to divert attention off the actual
point, because you don't have a rebuttal.

 

[Mark McIntyre]

inexplicably, I didn't see your original post. Did ERT answer it
immediately? My reader has a "fry all tisdaleposts" setitng.

Anyway to respond to you now, sorry, but I won't retract. I've read
through his reasoning several times, and its IMHO wrong. Since he
persists in holding a wrong position, I consider him idiotic on this
point.
Note that this isn't a general position, merely on the malloc point.

We've been over it many many times, and while I appreciate his work
circumstances make it much more convenient for him to cast malloc,
thats not a valid reason for advocating it to C programmers.

 

[E. Robert Tisdale]

If we go into things that are not C, then why not

allocate (p, 1);

with a new library function "allocate" which takes two arguments: An
lvalue p which must be a pointer to a complete type, and an integer. The
function would allocate space for as many objects as the integer
specifies and store the result in the pointer variable.

No chance to cast anything, so the whole argument would go away

No. Pointer p could never be a constant.

 

[Mark McIntyre]

I suspect Mark thought you were claiming that a (non-null) void *
value *returned by malloc* could point to an area that was
incorrectly aligned for double.

Yes, since this was the topic under discussion !

I also suspect Mark did not recognize your name, or he might have
double-checked before posting

I recognised it very well indeed, and I elected to post anyway,
because I believe that when it comes to malloc casts, PJ has the
programming equivalent of a crush on a beautiful but unsuitable woman,
and is unable to see that she's stealing his money, sleeping with his
friends and using his house to sell dope from....

Of course, my suspicions may be ill-founded.

Nope!

 

[Mark McIntyre]

If it's the kind with jokes printed on the roll, then it needs to come
over the top so it will be readable.

Depends what position you adopt when using the facilities....
=:-0

 

[P.J. Plauger]

Correct. But not these two. The two positions are

1) putting in malloc casts is perfectly ok, its harmless.
2) putting in malloc casts is unnecessary and therefore not ok.

I'm beginning to understand the communication problem here.
I've never espoused either of these posiitons, but that seems
to be what you've read.

But you're not in that camp. Youre in the "casting malloc is a good
thing" camp, as your own postings both in this thread and elsewhere
have showed.

Not to me.

As I said, I respect you enormously. You mistake intolerance of your
one stupidity for lack of respect

Uh yes, I *do* consider intolerance a lack of respect. Fortunately for
me, I don't really give a rat's ass whether you respect me or not.
I've been staying in this discussion for a variety of tutorial
purposes (which IMO I've been achieving).

I'd not know, I don't have one.

And yet you can be intolerant. An interesting pair of positions
to reconcile.

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

 

[P.J. Plauger]

How are casts from malloc() superfluous? Code should work identically
whether the casts are there or not.

I personally never said that casts from malloc() are superfluous,
just whitespace. And how code "should work" is just one factor to
consider in developing style rules.

However, code that uses casts is
different from that which does not in cases of failure to properly
declare malloc(). In that case they convert a int into a pointer.

Right. And other failures are caught when casts *are* present that
are obscured when they're omitted. It's a tradeoff, a matter of
choosing relative weights. Once you decide that any one weight is
a binary choice between okay and idiocy, you may as well divide
through by zero.

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

 

[P.J. Plauger]

Igenerallydon'twhenitdoesn'tmatter-haveyoueverseenwebbytheway?

Joking aside, you're actually reinforcing one of the arguments against
casting. One should write for readability. Whitespace (used
approriately) improves that. Casts (used appropriately) improve that.
Casts stuck in where unnecessary do not improve that.

Again you're applying one set of weights and value judgements with
nary a thought that other weights might be valid in other contexts.

This statement has a fine legal name, which escapes me for the moment.
Its something to do with trying to divert attention off the actual
point, because you don't have a rebuttal.

Well, maybe. Had I stopped there, you might have a legitimate gripe.
But the part you snipped went on to discuss the various answers I've
given.

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

 

[P.J. Plauger]

Yes, since this was the topic under discussion !


I recognised it very well indeed, and I elected to post anyway,
because I believe that when it comes to malloc casts, PJ has the
programming equivalent of a crush on a beautiful but unsuitable woman,
and is unable to see that she's stealing his money, sleeping with his
friends and using his house to sell dope from....

Now you're simply being a jerk. From your earlier posting:

: This statement has a fine legal name, which escapes me for the moment.
: Its something to do with trying to divert attention off the actual
: point, because you don't have a rebuttal.

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

 

[P.J. Plauger]

Anyway to respond to you now, sorry, but I won't retract. I've read
through his reasoning several times, and its IMHO wrong. Since he
persists in holding a wrong position, I consider him idiotic on this
point.
Note that this isn't a general position, merely on the malloc point.

I've now accumulated enough evidence that you're incapable of
reading accurately what others write, particularly when you don't
agree with them. It is no longer amusing that you keep calling
my position idiotic; now it is merely sad. My part of this discussion
is nearing its end. (And you accuse others of trolling...)

We've been over it many many times, and while I appreciate his work
circumstances make it much more convenient for him to cast malloc,
thats not a valid reason for advocating it to C programmers.

And you haven't even noticed that I'm *not* advocating this
position to C programmers in general. I've merely been defending
why it might sometimes be a reasonable position for some C
programmers in some contexts. The only thing I really can't stand
is intolerance. But you can only push that button of mine so many
times before I learn to tune it out.

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

 

[Richard Heathfield]

No. Pointer p could never be a constant.

With one exception, each word on the first line of Christian's reply is
monosyllabic. How on /earth/ did you manage to misunderstand it?

 

[Sidney Cadot]

Why would a C++ compiler need to worry about malloc()'ing code?

To be compliant with the relevant standard, ISO 14882.

They have memory allocation schemes of their own in C++.

So they do, but in addition, malloc(), free(), and friends are also
supported, with semantics that are pretty close to C semantics. No
points for guessing why that is.

All my loop indexes are called 'new' just to prevent accidental
> C++ compilation C code (okay, not really).

I fail to see your point.

No, two languages. One that has malloc() and does not require a cast and a
language that cannot prohibit the use of the former's memory allocation
function but that does require a cast.

Let me get this straight: do you deny there are to sides to this issue?
This seems to be somewhat implied by the "No".

Yours may well be bigger than mine, but surely, there /are/ two sides.

With Mr. Plauger, I am amazed by the complete inability demonstrated by
many of the 'anti-cast' crowd to admit even a hint of nuance in their
thought process on this issue. Being 'pro-cast' myself, I see perfectly
well the limitations of my view and see the good sense in some of the
arguments of those I disagree with. In fact, when commenting on code
that does malloc casting here in c.l.c., I have repeatedly pointed out
that malloc casting is generally not considered good style by most
regulars. A minimal amount of reciprocity would be welcome.

Best regards,

Sidney