back
1 comments
in just about every sense. when K&R wrote the 2nd ed of The C Programming Language, they ran all their examples through Stroustrup's then new C++ compiler (there was no ANSI C compatible compiler at the time) - the number of type problems it diagnosed shocked them.
I meant today, not in the past when C did not yet have prototypes. This is irrelevant today.
well. the classic is:+-

    int * p = malloc( sizeof(int) );
which is horrible in either language, but is legal c, but not c++
In C you could write or have a macro which does the cast.

  int *p = malloc(sizeof *p);
In C++ you would have to add an explicit cast, which would not make it safer:

  int *p = (int*)malloc(sizeof char);
So from a type system perspective this is not safer.
it is safer. because you have to make the explicit cast, which either the compiler or a linter can, and should, warn you about.

and your post does not illustrate a macro. and if it did, the compiler/linter could diagnose it.

This is the fallacy: A cast does not make code safer you have to use it for regular code that has no issue. Because a linter warning about that is just noise. By example illustrated a bug in the C++ code hidden by the cast.
any source or article on this?
the introduction to TCPL 2nd ed - the ansi one