Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > to cast or not to cast malloc ?

Reply
Thread Tools

to cast or not to cast malloc ?

 
 
MSG
Guest
Posts: n/a
 
      02-06-2004
The answer is neither. Use macros.

#define ALLOC(size, type) ((type) *) malloc((size) * sizeof(type))
#define NEW(type, name, size) (type) * (name) = ALLOC((size), (type))

They are both [more] type-safe and concise.

Compare:

NEW(int, x, 1000);

to

int * x = (int*) malloc(sizeof(int) * 1000);


I'm sure someone must have "discovered" this before. Anyways HTH.

MSG
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      02-06-2004
MSG wrote:

> The answer is neither. Use macros.
>
> #define ALLOC(size, type) ((type) *) malloc((size) * sizeof(type))
> #define NEW(type, name, size) (type) * (name) = ALLOC((size), (type))
>
> They are both [more] type-safe and concise.
>
> Compare:
>
> NEW(int, x, 1000);
>
> to
>
> int * x = (int*) malloc(sizeof(int) * 1000);


If you must compare, at least compare to good code:

int *x = malloc(sizeof *x * n);

> I'm sure someone must have "discovered" this before. Anyways HTH.


Yes, they're hardly new, I'm afraid.

Presumably you have equivalents for all the other functions returning a void
pointer? Not just the standard library functions (memchr, memset, bsearch,
calloc, realloc), but all the third-party libraries, too?

If not, you'd better get busy. When the /whole set/ is completed, fully
tested, and guaranteed by ISO to work correctly, I'll start using them.
Deal?

--
Richard Heathfield : http://www.velocityreviews.com/forums/(E-Mail Removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
 
Reply With Quote
 
 
 
 
E. Robert Tisdale
Guest
Posts: n/a
 
      02-06-2004
Richard Heathfield wrote:

> If you must compare, at least compare to good code:
>
> int *x = malloc(sizeof *x * n);


Both P. J. Plauger and Bjarne Stroustrup disagree with you.
It isn't good code.
It's a bad habit that was "grandfathered" into the standards
so that the standard wouldn't break all of the existing bad code.

Please reference recent articles in the comp.lang.c newsgroup.

 
Reply With Quote
 
Clint Olsen
Guest
Posts: n/a
 
      02-07-2004
On 2004-02-06, E. Robert Tisdale <(E-Mail Removed)> wrote:
>
> Both P. J. Plauger and Bjarne Stroustrup disagree with you. It isn't
> good code. It's a bad habit that was "grandfathered" into the standards
> so that the standard wouldn't break all of the existing bad code.
>
> Please reference recent articles in the comp.lang.c newsgroup.


I trust Steve Summit's opinion far more than I do yours, so the rest of us
will leave off the cast, thanks.

-Clint
 
Reply With Quote
 
Allin Cottrell
Guest
Posts: n/a
 
      02-07-2004
E. Robert Tisdale wrote:
> Richard Heathfield wrote:
>
>> If you must compare, at least compare to good code:
>>
>> int *x = malloc(sizeof *x * n);

>
>
> Both P. J. Plauger and Bjarne Stroustrup disagree with you.
> It isn't good code.
> It's a bad habit that was "grandfathered" into the standards
> so that the standard wouldn't break all of the existing bad code.


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

First, my only objection to Richard's example is purely stylistic;
I find it clearer on the eye to write:

int *x = malloc(n * sizeof *x);

rather than

int *x = malloc(sizeof *x * n);

(There's something a little confusing about the two '*'s in close
proximity in the version Richard wote above.)

Second, leave Mr Stroustrup out of it. I'm sure he is (or was) an
expert C programmer, but his commitment to C++ renders him an
unreliable witness in this case (C++ requires that the return of
malloc be cast to the type at issue -- although, as others have
noted, use of malloc is not really idiomatic in C++ anyway).

That leaves the reference to Mr Plauger, who is assuredly an
expert in C. In previous discussions of this point on clc we
can distinguish Plauger1 and Plauger2.

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

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

--
Allin Cottrell
Department of Economics
Wake Forest University, NC
 
Reply With Quote
 
Sidney Cadot
Guest
Posts: n/a
 
      02-07-2004
Allin Cottrell wrote:

> [...]


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


So are trigraphs. The "because we can" argument is fundamentally
unsound, IMHO. There are several good reasons for not casting malloc
results, but the fact that C /allows/ them to be not casted is not one
of them.

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


Which one, C89 or C99? Because with C99, the stdlib.h argument (which is
weak already because of modern compilers) goes entirely out the window.

Best regards,

Sidney

 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      02-07-2004
Allin Cottrell wrote:

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


No.
The standard allows programmers to do all kinds of things
that are *not* necessarily "good programming practice".
C is *not* Ada. C programmers are given a cocked and loaded fire arm
with the safety turned off.
All they need to do is point it at the remaining foot and blow it off.
Good programming practice is the exercise of [self]discipline.

According to Plauger, the implicit conversion from *void
to any other pointer type is the result of poor programming practice
and a lack of [self]discipline. The were compelled to include it
in the standard because so much bad code had already been written.

 
Reply With Quote
 
Allin Cottrell
Guest
Posts: n/a
 
      02-07-2004
Sidney Cadot wrote:

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

>
> So are trigraphs. The "because we can" argument is fundamentally
> unsound, IMHO. There are several good reasons for not casting malloc
> results, but the fact that C /allows/ them to be not casted is not one
> of them.


The actual nature of C makes the cast redundant. The insertion
of redundant casts -- not their omission -- requires some sort
of special justification. This is my point.

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

>
> Which one, C89 or C99? Because with C99, the stdlib.h argument (which is
> weak already because of modern compilers) goes entirely out the window.


Suppose "the C standard" is some sort of weighted average of C89 and
C99, the weights depending on the context of the discussion. As the
weight on C99 approaches 1.0, the stdlib.h argument approaches
negligibility. The argument that redundant casts are best
avoided retains its full force. The Plauger1 argument that some
code may have to be compiled as C++ retains its orthogonality to
the issue of good C practice. The notion that "we really ought
to have to cast the malloc return and it's a shame we don't"
retains its irrelevance.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      02-07-2004
On Fri, 06 Feb 2004 15:27:19 -0800, "E. Robert Tisdale"
<(E-Mail Removed)> wrote in comp.lang.c:

> Richard Heathfield wrote:
>
> > If you must compare, at least compare to good code:
> >
> > int *x = malloc(sizeof *x * n);

>
> Both P. J. Plauger and Bjarne Stroustrup disagree with you.
> It isn't good code.
> It's a bad habit that was "grandfathered" into the standards
> so that the standard wouldn't break all of the existing bad code.
>
> Please reference recent articles in the comp.lang.c newsgroup.


Another one of your utterly foolish replies, I'm afraid. Since there
was no void or pointer to void in K&R C, malloc() in those days was
defined as returning a pointer to char. All calls to malloc() that
allocated memory to be used for other types than char required the
cast.

So it is quite obvious that there was nothing to "grandfather" in this
regard.

As for Stroustrup, note that C++ allows the implicit conversion TO
pointer to void FROM pointer to any other object type, as does C, just
not the reverse. The reasoning for this strikes me as a little
suspect. Unlike, I hasten to add, most of Dr. Stroustrup's other
design decisions in the development of C++. Also note that he has
proposed allowing the void pointer to object pointer conversion in a
future version of the C++ standard.

Plauger gave very specific reasons for his preference, and it really
has nothing to do with C and everything to do with C++.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-07-2004
Allin Cottrell wrote:
>

.... snip ...
>
> Plauger2 (I think) goes further, and bemoans the fact that
> automatic conversion from (void *) to (whatever *) was ever
> accepted into standard C. 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.


I never noticed that! If true, Trollsdale has learned yet another
evil trick. At any rate the only one who can say for sure is P.J.
Plauger, who should object violently to any such happenings.
Impersonation is not looked upon with favor by ISPs.

In fact, the very continued presence of Trollsdale here tends to
argue against his having practiced such a trick.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
to malloc or not to malloc? kj C Programming 5 06-05-2009 02:22 PM
to malloc or not to malloc?? Johs32 C Programming 4 03-30-2006 10:03 AM
free'ing malloc'd structure with malloc'd members John C Programming 13 08-02-2004 11:45 AM
Re: free'ing malloc'd structure with malloc'd members ravi C Programming 0 07-30-2004 12:42 PM
malloc - to cast or not to cast, that is the question... EvilRix C Programming 8 02-14-2004 12:08 PM



Advertisments