4 ms·

6.5:6 is certainly not saying that malloced memory always aliases with “everything”. Quite the contrary, it says that malloced memory cannot be used for type-pu

6.5:6 is certainly not saying that malloced memory always aliases with “everything”. Quite the contrary, it says that malloced memory cannot be used for type-punning. The following works and is idiomatic: uint32_t u; float f = …; memcpy(&u, &f, sizeof u); /* use u as a uint32_t in computations */ You cannot do the same thing with malloced memory: if u had been malloced memory instead of a variable, it would have been illegal to access that memory with an lvalue of type uint32_t in subsequent computations. 6.5:6 is certainly no license to use malloc'ed memory any which way.

sharpneli 11y ago
There is a non-normative note in 6.5:6 "Allocated objects have no declared type." Sure that is not strictly part of the standard. But helps in interpreting it. I'd say it quite clearly refers to malloced objects. Malloced object is an object with no declared type. If you look at the bug report it uses malloced object as the example. And accesses it using two pointers of different types.
- nkurz 11y ago
  I think you are misinterpreting Pascal's example. He's saying that because 'u' is a variable with a declared type (uint32_t), it can still be used as that type even after it is written to with another type. He then claims that were it an "allocated object" with no declared type, the effective type would change to the type of the most recent write (float), and thus it could no longer be used as the original type (uint32_t). I'm not sure he's right, though. The quoted part of the standard says "stored into an object having no declared type through an lvalue having having a type that is not a character type". I would think that "through an lvalue" is referring only to the case given in the bug report, where the store is expressed as "*ptr = val", and not to the case where ptr is used as an argument to memcpy(). Am I wrong?
  - sharpneli 11y ago
    You're right. I did misinterpret it. However I also think you're right. Memcpy is effectively the same as through a character type in the end.
asgfoi 11y ago
Uh, thanks for pointing that out. I'm familiar with allocated memory and effective type, but I never considered it from this perspective. This could be quite a nasty surprise when the only change in the code is storage duration.

sharpneli 11y ago

There is a non-normative note in 6.5:6 "Allocated objects have no declared type." Sure that is not strictly part of the standard. But helps in interpreting it. I'd say it quite clearly refers to malloced objects. Malloced object is an object with no declared type. If you look at the bug report it uses malloced object as the example. And accesses it using two pointers of different types.

nkurz 11y ago
I think you are misinterpreting Pascal's example. He's saying that because 'u' is a variable with a declared type (uint32_t), it can still be used as that type even after it is written to with another type. He then claims that were it an "allocated object" with no declared type, the effective type would change to the type of the most recent write (float), and thus it could no longer be used as the original type (uint32_t). I'm not sure he's right, though. The quoted part of the standard says "stored into an object having no declared type through an lvalue having having a type that is not a character type". I would think that "through an lvalue" is referring only to the case given in the bug report, where the store is expressed as "*ptr = val", and not to the case where ptr is used as an argument to memcpy(). Am I wrong?
- sharpneli 11y ago
  You're right. I did misinterpret it. However I also think you're right. Memcpy is effectively the same as through a character type in the end.

asgfoi 11y ago

Uh, thanks for pointing that out. I'm familiar with allocated memory and effective type, but I never considered it from this perspective. This could be quite a nasty surprise when the only change in the code is storage duration.