← Back to context

Comment by uecker

6 hours ago

My macro-vector types are type safe. In fact this is the point.

I do not think C++ is more expressive or type safe.

In C, assigning the return value from malloc() to a specific type merely produces a warning:

  $ echo -ne "#include <stdlib.h>\nint foo() { return malloc(42); }" | gcc -xc -fsyntax-only -c -
  <stdin>: In function ‘foo’:
  <stdin>:2:20: warning: returning ‘void *’ from a function with return type ‘int’ makes integer from pointer without a cast [-Wint-conversion]

Whereas in C++ it's a hard error:

  $ echo -ne "#include <stdlib.h>\nint foo() { return malloc(42); }" | gcc -xc++ -fsyntax-only -c -
  <stdin>: In function ‘int foo()’:
  <stdin>:2:26: error: invalid conversion from ‘void*’ to ‘int’ [-fpermissive]

Does this not count as "more type safe" to you?

  • No, this counts as C++ is stupid to me. The memory returned by malloc is UNTYPED. The sole reason why void as a type exists is to convey the notion of no type, so that it needs to be assigned to a type by a programmer. If you mean "byte region, please cast before use" that's 'char *'. Since C++ now forces me to write a cast, it effectively forces me to hide and silence errors.

    I do want an error when I violate types, I do not want it for void, because that's the whole meaning of void. C++ manages to make it the worst of both worlds.

    • Nah. Malloc’s return type is a pointer. The memory pointed to by a malloc call is untyped. But the return type isn’t void. It’s void*, aka a pointer to unknown.

      I’m mostly happy with implicit casts from void* to int* or something. But in this code example, we see an implicit cast from void* to int, casting the pointer itself into a number that might not even fit the pointer. This is rarely what you want. I’d much rather explicit casts in this case.