Re: Is it legal to type cast to DWORD* ???

From: __PPS__ (
Date: 07/10/04

Date: 10 Jul 2004 09:32:56 -0700

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,
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
} data;

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];
} 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
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.

Relevant Pages

  • Re: "Portability" contructs like UINT32 etc.
    ... All those WORDS, DWORDS, LPCSTR, HPARAMS, LPARAMS etc. ... I have a real problem with "WORD" and "DWORD" which is used in Windows programs a lot: "WORD" is defined as a 16 bit type and DWORD as a 32 bit type, which means that on your average Pentium or Athlon processor a WORD is a halfword and a DWORD is a word, whereas on a 64 bit processor a WORD is a quarterword and a DWORD is a ... And LPCSTR - "Long Pointer to C String". ... You see, char* is typedef'ed to PCCHAR (yes, ...
  • Re: a common belief or a wrong C[++] compiler?
    ... >so a general understandable way for algo-expressions could be the ... dword mult ... dword crpt (pointer to char p, ...
  • GSoC: Avoiding syscall overhead
    ... needs to be pinned as to avoid having it be paged out. ... a struct with the process information. ... a process could mistakenly use the pointer to access ... (I just received my FreeBSD book today!) ...
  • Re: Questions about malloc()
    ... >> When you needs nappies you should avoid using C. Use Cobol instead. ... >> have a brain to think yourself. ... When you're unable to follow this you should avoid ... Test on each case where it is absolutely clear that a pointer ...
  • Re: How to avoid address alignment fault?
    ... I would think that the best way to avoid data alignment problems is to avoid casting of pointers. ... As long as you e.g. treat a pointer to a DWORD as a pointer to a DWORD, the compiler automatically aligns the data on a DWORD boundary. ... Unless you are sure that the casted CHAR-pointer is DWORD-aligned you'll run into alignment problems. ...