If you are targeting both C and C++, you do want to cast. If it's just C, the advice is not to cast because a) no point in repeating yourself, and b) it could mask an error if malloc was not declared.
a) is hardly an issue in a one-off macro definition, and b) is hardly an issue as you probably have #include <stdlib.h> just above the define. Besides, sane CFLAGS and any remotely modern compiler will protect you from b) anyway.
There is a minor benefit to casting in this case, as it will error out if I do:
int *x = new(x, 10); // should be new(int, 10)
because x is not a type.
However, I still think this is terrible advice because it turns something very standard that every beginner C programmer understands into something that requires familiarity with the codebase and incurs a constant cognitive load. It also makes for some very hard to debug errors if I use "new" as a variable name somewhere. Not to mention total incompatibility with C++ due to choice of name.
If you're #defining a macro, the cast is sensible because the macro did the allocation for that particular type => having the macro result cast protects against/warns when mistakenly assigning it to a pointer of different type.
Comments
Kind of a minor point, but isn't the consensus among C programmers that you shouldn't cast the result of malloc?
If you are targeting both C and C++, you do want to cast. If it's just C, the advice is not to cast because a) no point in repeating yourself, and b) it could mask an error if malloc was not declared.
a) is hardly an issue in a one-off macro definition, and b) is hardly an issue as you probably have #include <stdlib.h> just above the define. Besides, sane CFLAGS and any remotely modern compiler will protect you from b) anyway.
There is a minor benefit to casting in this case, as it will error out if I do:
because x is not a type.However, I still think this is terrible advice because it turns something very standard that every beginner C programmer understands into something that requires familiarity with the codebase and incurs a constant cognitive load. It also makes for some very hard to debug errors if I use "new" as a variable name somewhere. Not to mention total incompatibility with C++ due to choice of name.
On the contrary. you must cast it or get a warning in modern compilers (and an error if you compile it in C++ mode).
The “don’t cast” consensus is about NULL remaining 0L and not of any pointer type (as was the case in some standard libraries in the early 90s)
Note also that the comma should be an asterisk.
It's fine in C and you won't get a warning (just try int *p = malloc(sizeof(int)) with gcc -Wall).
I really doubt any compilers will warn on void* casts in pure C. Usually the warning is if you do:
or similar. But if x was "void*", it really should work on all C compilers.If you're #defining a macro, the cast is sensible because the macro did the allocation for that particular type => having the macro result cast protects against/warns when mistakenly assigning it to a pointer of different type.