Is there some compiler directive (like "no strict aliasing" or something else) which might prevent union fields to be overstored in the most straight forward intuitive way?
thank you
Is there some compiler directive (like "no strict aliasing" or something else) which might prevent union fields to be overstored in the most straight forward intuitive way?
thank you
aliasing is just telling the compiler that memory pointed to by pointers may change memory pointed to by other pointers [so the pointer P1 is an alias for the memory block pointed to by P2]. It does not affect what and how things get stored in unions.
What is the problem you are trying to solve, what does your union look like?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
thank youOriginally Posted by matsp
I still have to read the code of a colleague which uses unions very much to interface different HW ports or devices or implement protocols but I dislike unions (personal taste) and have some worries about bugs hiding under the corner when changing platforms..
I am not saying it's very likely to be a problem, it is just a fear..
basically union members overlapping can change depending on the platform (I guess, just because size of types change on different platf.) so using them relying on a specific overlap (as is done by my colleague) seems to me risky
Unions, like many other "tools" have their benefits and their drawbacks. The purpose of a union is to make data of several formats be available at the same place - obviously, it's up to you to KNOW what the data represents, and which format can be used at which time. Unfortunately, any alternative to unions is at least as likely to fail at times - one of the obvious solutions is to use the address to the data [in a pointer] and then use casts to change the interpretation of the content. I think that, generally, means that the code gets harder to read.
Of course, one alternative is to store the data spaced out in a struct instead, but if you have even a reasonable amount of alternatives, you can easily increase the space needed for the fields by several times, which is not a good idea [and you would still need to know which part to use at what time].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Would you feel better if he used int_32t (or whatever fixed-width type is appropriate) instead of int?
well that works for POSIX
what about Microsoft?
The same thing works - you may have to make your own typedef for int32_t (etc), but the concept holds true.
ALWAYS use your own types if size of the type matters.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
