Thanks guys for your replies - it helped alot - from now on I will
avoid this problem.
Why I used it:
I wrote a simple class for cerating and sending radius packets, radius
client (rfc2865) to make it faster and easier to use for an opensource
project that is run on almost all unixes, windowses, macos, solaris,
etc...
and I defined a radius pdu like this:
NOTE: it should be exactly 4096 bytes in size to avoid misaligned
fields at some places, if all the fields are chars, hopefully, it will
always be (if some compiler doesn't think it could be more)
class something{
union {
unsigned char as_raw_data[4096];
struct {
unsigned char code;
unsigned char identifier;
unsigned char length[2];
unsigned char authenticator[16];
unsigned char pdu[4076]; //this later contains list of
attributes.
}as_pdu;
} data;
public:
....
....
};
When preparing a packet to be sent sometimes the unsigned char
authenticator[16]; field is set to random 16 bytes. I do it using
mersenne twister pseudorandom like this (random is a static instance
of a class)
*(DWORD*)(&data.as_pdu.authenticator[0]) = random;
*(DWORD*)(&data.as_pdu.authenticator[4]) = random;
*(DWORD*)(&data.as_pdu.authenticator[8]) = random;
*(DWORD*)(&data.as_pdu.authenticator[12]) = random;
As you can see authenticator is 4 bytes aligned to data - will data
(data is the name for the structure) be aligned to to 4 bytes or it's
unaligned? I'm going to change my code to reflect your comments, but
fot the sake of better knowlege I have other questions:
if I defined pdu like this:
union {
unsigned char as_raw_data[4096];
struct {
unsigned char code;
unsigned char identifier;
unsigned char length[2];
union {
unsigned char authenticator_as_chars[16];
unsigned int authenticator_as_ints[4]; //each 4 bytes...
}
unsigned char pdu[4076];
}as_pdu;
} data;
I wouldn't probably have this problem with:
authenticator_as_ints[0] = random;
authenticator_as_ints[1] = random;
authenticator_as_ints[2] = random;
authenticator_as_ints[3] = random;
BUT, would my structure still be 4096 in total? (Looks like it should
be for systems that I do test on - what about others??)
//////////////////////////////
Jack Klein wrote:
I don't know, you haven't provided a definition of the type DWORD,
which is not a standard C++ type.
So then, how could you possibly answer my question??
Who says it is "perfectly legal"?
What I was sure is that it doesn't make any difference with simple
(DWORD*)pointer cast,
as value of pointer itself is not chaged. But accssing data as char or
dword
pointed by a pointer makes difference (at least for some processors.)
differences are not mentioned about performance - it's about errors.
If I didn't express myself clearly - sorry then.
DWORD was intended to indicate 4 bytes - it wasn't about standart
or not - most of the people undestood what I meant.
