Re: malloc syntax

From: Sidney Cadot (sidney_at_jigsaw.nl)
Date: 11/22/03 

Date: Sat, 22 Nov 2003 03:02:53 +0100

August Derleth wrote:

> I can't be held accountable for all of the crap the Standard implicitly
> condones. ;)
>
> The fact is that casting the return value of malloc (and all of the 'alloc
> clan) is rather stupid and is a habit that should be broken in all C
> programmers. It hides another error and implies a fundamental
> misunderstanding of the whole point of having a pointer to void type.

In all seriousness, I think the implication is a false one. I think I do
understand the point of having pointers to void in a language like C,
yet I am in favor of malloc() casts, both from a practical and a
theoretical point-of-view.

Admittedly, a few weeks ago when this came up some genuine disadvantages
  were identified, but none of them was a completely convincing reason
for me to change (some would say mend) my ways in this respect.

Now I am not usually one to invoke Bjarne Stroustrup as a source of
profound wisdom, but I hope that you will agree that he knows a thing or
two about C. Of course, C++ doesn't allow implicit casts from void* to
pointers of any other types, and the reason is given in $5.6 of "The C++
Programming Language". After stating allowed operations on void*, it
continues "Other operations would be unsafe because the compiler cannot
know what kind of object is really pointed to."

Now in C of course, other operations are defined, such as implicit casts
to other pointer types. Hesitantly, but surely, I agree deeply with Mr.
Straustrup that this is a bad idea, and I consider this one of the messy
points in C. The fact that it is _allowed_ doesn't make it right, as far
as I am concerned.

Please understand that I don't want to re-open this particular issue for
debate; I would simply urge you to be careful with implying lack of
understanding of C features from things that are at least partly a
matter of style. I think casting malloc() results is not a practice that
  merits disqualification of the practioner out of hand.

Surely, I don't like casting any more than the next guy; I've had to
wade through student's code littered with them a couple of hundreds
times too many for that. A cast, to me, is a legit operation if and only
  if it serves to correct the idea that the compiler has about the type
of an expression, based on knowledge that I, the programmer have - but
the compiler doesn't. malloc(100*sizeof(double)), to me, is such a
situation. Concluding from this that I don't get the point of void*,
borders on being offensive. But I'm sure it wasn't intended that way.

Best regards,

   Sidney

Relevant Pages

  • Re: confusion: casting function pointers
    ... pointer from the 'actual/other modules' that takes arguments of type ... list to types of void *). ... int main{ ... without a prototype, a number of special "promotion" rules take ...
    (comp.lang.c)
  • Re: [RFC] timers, pointers to functions and type safety
    ... * they have callback of type void ... callback is called by the code that even in theory has no ... cast to unsigned long and cast back in the callback. ... number - not a pointer cast to unsigned long, not an index in array, etc. ...
    (Linux-Kernel)
  • Re: Can I Trust Pointer Arithmetic In Re-Allocated Memory?
    ... You can't do pointer arithmetic on a void* value. ... qsort behaves in a manner consistent with its specification. ... actually works as advertised...but doesn't mean that the cast is ...
    (comp.lang.c)
  • Re: The void** pointer breaking symmetry?
    ... void** is a generic pointer type that can be implicitly converted ... because dereferencing the void ** variable once gives ...
    (comp.lang.c)
  • Re: Maps, filters and accumulators
    ... void pointer they get back to a pointer to the appropriate type of data. ... int(*compar)(const void *, const void *)) ... avoid having to do all that work (either by getting a code generator to ...
    (comp.lang.c)