Re: to cast or not to cast malloc ?

From: P.J. Plauger (pjp_at_dinkumware.com)
Date: 02/07/04 

Date: Sat, 07 Feb 2004 16:38:31 GMT

"Allin Cottrell" <cottrell@wfu.edu> wrote in message
news:c01eu2$1ama$1@f1n1.spenet.wfu.edu...

> OK, this is my last posting on this topic (promise, I think).

Me too, I hope.

> Plauger1 offers the argument that in some special contexts there
> is a need for C code that can also be compiled as C++. In that
> case, as most participants in the debate have acknowledged,
> sticking a cast in front of the malloc return is OK, so long as
> we can be sure that stdlib.h has been included. However, this
> special case hardly justifies the notion that casting the
> return from malloc is in general "good C practice".

Nor did I ever promote casting malloc as general good C practice.
I merely pointed out (repeatedly) that the opposition to casting
malloc has become kneejerk in this forum. I have an active dislike
for any dogma that replaces thought. IM(extensive)E I've encountered
several occasions where it makes good sense to add the casts, and
I tried to describe one or two of them. The kneejerks took these
descriptions as attacks on their beloved style rule (which they
were not), and as rival dogma (which it is not).

FWIW, I would advise most C programmers *not* to cast malloc calls,
for most of the reasons advanced by others in this forum.

> Plauger2 (I think) goes further, and bemoans the fact that
> automatic conversion from (void *) to (whatever *) was ever
> accepted into standard C.

Nope. I never bemoaned it. On the contrary, I helped work out the
rules and voted in favor of adding this capability. The one regret
I expressed is that we used the notation of C++ for this purpose.
Practically every case where we coopted C++ notation and altered
its meaning has proved to be a problem in subsequent years.

> To Plauger2 (who may not correspond
> to the real P.J. Plauger, but apparently does correspond to
> E.R. Tisdale) I say, "Get over it!" Such automatic conversion
> _is_ part of ISO/ANSI standard C and has been for well over a
> decade. Good C programing is defined in relation to the
> actually existing standard, not some people's notion of what
> the C standard ought to have been.

Not exactly. It's defined in relation to the C Standard *and the
requirements of a given programming project*. Nothing in the C
Standard says you should format your code neatly. And nothing
says you shouldn't. Yet it is a poor project that has no rules
about code layout. Religious wars have been fought for decades
over the proper placement of braces, in part because there's
often really no compelling reason to favor one scheme over
another -- it all depends on what weights you give a handful
of layout principles. (Again FWIW, I pioneered one of the now
popular styles, known as the Whitesmiths style, but I myself
don't adhere to it slavishly.)

It is a curious failing of techies that they mistake *all*
their opinions as the product of rational thought. We all
think with our hormones from time to time; it really helps to
notice when you're doing so. IME, the zeal with which a techie
defends a debatable opinion varies inversely with its rational
defensibility.

Put your casts, and your braces, where you may. But do please
try to think, from time to time, about *why* you're doing what
you're doing. More to the point, when somebody comes up with
a different set of style rules, consider the possibility that
they might not be completely misguided. You might learn
something.

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

Relevant Pages

  • Re: unusual behaviour of program under linux....
    ... >> You don't need to do this cast. ... You need to stop casting the return value from malloc(). ... The ISO/ANSI C Standard says the some ways of arranging C code ... Undefined behavior is another one you will want to learn ...
    (comp.unix.programmer)
  • Re: (FAQ details:) malloc(), void * and casts
    ... In many older implementations of the standard library, malloc is defined ... to return a char * rather than a void *, so including the cast makes ... The original ANSI Standard was adopted in 1989. ...
    (comp.lang.c)
  • Re: access of memory beyond allocation, not causing segmentation fault...
    ... conversion allergies in many programmers. ... You and Richard Bos give poweful reasons for losing the cast from malloc(). ... But for my point to fall, those who retain the cast would have to offer as "no evidence" position. ... You shouldn't try to draw too many conclusions about the fact that a behaviour is undefined by the C standard, except to say that it is not a correct C program, according to that standard. ...
    (comp.lang.c)
  • Re: C99 Question
    ... > the return value of malloc should not be casted? ... The ANSI/ISO C 99 standard does *not* say that ... There is *no* advantage to omitting the cast. ...
    (comp.lang.c)
  • Re: problem with memcpy and pointers/arrays confusion - again
    ... this second method is known as an explicit conversion, or cast. ... The cast, in effect, tells the compiler: ... the malloc function. ... function taking a size_t as a parameter and returning a void pointer (i.e. ...
    (comp.lang.c)