"Being able to be sure of the element size is not enough. You also need
to know the number of the elements. For example, you might want to
allocate 10 foo_t's to variable a and 15 bar_t's to variable b. If you
do not cast malloc(), there is a possibility that you are allocating
a's elements to b and b's elements to a.
"Using p=malloc(10*sizeof(*p)) will not help because it's a problem
with the 10, not with the sizeof(*p). So we need casts to make the
compiler complain if we allocate foo_t's to a bar_t * or vice versa."

Once again, I could not find a counterargument. What do you C gurus
say about this?

int *p = malloc(10 * sizeof *p);

bar_t *b = malloc(15 * sizeof *b);

Note that this syntax works for *any* type.

Have him read a C text about malloc(), noting its
return type, and about the rules governing implicit
conversions, esp. those for pointers.

     In case if you are not reading the entire thread, here is a
partial summary of the previous thread: the major opponents cite
the case of missing <stdlib.h> combined with malloc casts;
whereas the major supporters cite the case of hidden diagnostics
when <stdlib.h> is there but the malloc casts are removed.  Both
of them could potentially hide a huge bug.

     For average programming projects, you probably don't need
malloc casts, because usually their data structures are quite
straightforward.  OTOH, if your team leader is extremely creative
and is fond of inventing hundreds of novel and deeply-nested data
structures with all sorts of simulated polymorphisms, then you
will love the malloc casts.

     Which situation are you in now?

     #include <stdio.h>
     #include <stdlib.h>
     #include "foo.h"

     void a_func(void *a) {
          a_t *foo = (a_t *) a; foo->data = 1;
     }

     void b_func(void *b) {
          b_t *foo = (b_t *) b; foo->data = 2.0;
     }

     int main(void) {
         global = (a_t *) malloc(sizeof *global);
         a_func(global);
         /* More code here... */
         return EXIT_SUCCESS;
     }

     Everything is working fine until a third party checks in the
following modified code:

foo.h:
     struct a_t { int data; };
     struct b_t { double data; };
     /* a_t */ b_t *global; /* modified by a third party */

     This incorrect program will now trigger a compiler warning,
because the Standard guarantees the diagnostic.  This mandatory
warning message is very useful for locating the bug made by the
third party.

     Now, do we have the same guarantee if we lose the cast?

main.c:
         global = malloc(sizeof *global);

     The answer is unfortunately no.  A conforming compiler is
licensed to silently accept this incorrect program when the
malloc cast is omitted.  As this example shows, malloc casts can
be useful at times.

foo_t *a = malloc(10 * sizeof(foo_t));
bar_t *b = malloc(10 * sizeof(bar_t));

Then without a cast, you could be stupid and do:

foo_t *a = malloc(10 * sizeof(bar_t)); ?

A cast from malloc to foo_t* would prevent this, but I suppose this is one
of the reasons one should use: foo_t *a = malloc(10 * sizeof *a); instead?

I assume this is a discussion about whether to cast from malloc or not? If
that's the case, then I hear everyone say we should NOT cast from malloc,
as it could mean trouble if for example you forget to include the
declaration
of malloc (making it return an int instead of void *), right? But the
compiler
will give you a warning anyway, so what's the problem really?

Then why does K&R say that "The pointer returned by malloc or calloc has
the proper alignment for the object in question, but it must be cast into
the
appropriate type, as in: int *ip; ip = (int *)calloc(n,sizeof(int));"
(section 7.8.5)?

Should we not trust K&R this time, as I'm always told to do? I will cast my
malloc's as K&R does untill someone can explain to me why we should not
cast and why K&R are wrong! ;)

And btw, what does "proper alignment for the object" mean?

   users = malloc(ngroups * sizeof *users);

looks suspicious whereas

   users = malloc(nusers * sizeof *users);

makes sense. Adding a cast such as

   users = (User *)malloc(ngroups * sizeof *users);

adds nothing useful to this, it is just clutter.

[these 'address boundaries' are platform-dependent]

In Classic C, malloc() and calloc() had return type "char *", but
this was changed in 1989 and the need for the cast was removed.
Since pointer casts' main function is to disguise bugs, those of
us who have been using C since 1981 prefer to avoid them. :-)

[The team leader says:]

dave

[The team leader says:]

dave

"142: The remark about casting the return value of malloc ("the proper
method is to declare ... then explicitly coerce") needs to be rewritten.
The example is correct and works, but the advice is debatable in the
context of the 1988-1989 ANSI/ISO standards. It's not necessary (given
that coercion of void * to ALMOSTANYTYPE * is automatic), and possibly
harmful if malloc, or a proxy for it, fails to be declared as returning
void *. The explicit cast can cover up an unintended error. On the other
hand, pre-ANSI, the cast was necessary, and it is in C++ also. "

I don't know if it was Kernighan or Ritchie who wrote that, but I'm
fairly sure it was one or the other.

p = (foo_t *)malloc(10 * sizeof(foo_t));

cannot magically transform a 10 into a 15 if 15 was intended. Nor can p
= malloc(10 * sizeof *p), of course, but then it doesn't claim to.

The argument is spurious and flawed, as was his previous argument.