4 ms·
One problem is that, when you cast to `void*`, you discard size information. I have a `double*`, I know the size of the object behind that pointer is `sizeof(d
by shrimp_emoji 4y ago
One problem is that, when you cast to `void*`, you discard size information.
I have a `double*`, I know the size of the object behind that pointer is `sizeof(double)`. If I have a `void*`, and nothing else, all bets are off.
- masklinn 4y agoOP is saying that you don't need an explicit cast to cast from a void* (which is what malloc returns).
- shrimp_emoji 4y agoIn that case, I guess >C has a type system, but the developers are ignoring it, preferring to move stuff around as void *. is alleging that C programmers insist on literally keeping their allocated variables behind `void*`s. That's too weird to me. :p Because, yeah, you don't need an explicit cast from a `void*` returned from a `malloc`, and I assume everyone tacitly assigns that `void*` to a `Foo*` immediately. The only case where you're converting stuff to `void*`s is when passing/taking it to/from "generic" APIs, where it could be any type. (Hence "move stuff around".) I thought OP was alleging there's no problems with this practice, although that interpretation of mine doesn't make sense from what they said in retrospect.
- wizofaus 4y ago"Some non-zero multiple of sizeof(double)", surely?
- mananaysiempre 4y agos/non-zero // double x[1], *p; p = x + 1; /* legal though *p wouldn’t be */
- wizofaus 4y agoSurely in that case x[0] is the object "behind" the pointer (assuming adding 1 puts you ahead!). But using the orginally intended meaning of "behind" here, logically there is no object at all...