Yesterday, I learned that I had a completely wrong concept in mind of what typecasting in #C actually is.
Now, I learned about #punning, a ridiculously cumbersome way to save raw data of a variable of one type into memory of another type (say, I have `floats` and need to save them in a `uint32_t` typed memory space).
Granted, I am stupid, because instead of this, I could simply have two or more pointers to the memory region. One as type `uint32_t`, and one as `float`.
Still, both ways feel weirdly far-from-hardware, and thus un-C-ish.
Like, when I get to mess up memory, why make it so cumbersome?
Also: I hereby advocate to add #hardwarenah (adj.) to the English language.
@cweickhmann Having two pointers that alias each other and which are not of compatible types isn't really allowed and one reason why some code breaks when -fstrict-aliasing is active.
@pancomputans The whole reason I am doing this is to save a bunch of `float` settings to an EEPROM. But then I also want to save (and calculate) a CRC of the values to make sure, it does not load garbage.
Do you have an idea how to do this in a smart and reliable way?
@cweickhmann @pancomputans put your floats in a struct and call crc on the struct pointer and sizeof *pointer.
@slink
Struct to the rescue! Thanks!
@pancomputans
@slink @cweickhmann What you actually need to do is use memcpy to transfer the memory representation from one type to the other if you care about portability. To my knowledge that's the only standard conforming way. A struct can contain arbitrary padding.
@pancomputans @cweickhmann my answer would have been different for portability. mostly: binary portability for floating point numbers is a problem. for integers, you can adjust endianness by copying individual bytes in the right order.
just using memcpy is not enough.
@pancomputans I realise an MWE would make this more concrete, but I'd put this on stackexchange somewhere instead.