Pointer cast problem: from DWORD * to BYTE *

[Ewi]

Hi!

I'm very frustrated. I have to access the same data as DWORD values and at the same time as BYTE values. I did this (simplified):

1: DWORD dwBuffer[16];
2: PBYTE bBuffer = (BYTE *)dwBuffer;
3: dwBuffer[2]= dwFileSizeHi;
4: bBuffer[0] = (BYTE)0x80;

This doesn't work. I get an access violation at runtime at line 4.

If I change this to this:

1: BYTE bBuffer[64];
2: PDWORD dwBuffer = (DWORD *)bBuffer;
3: dwBuffer[2]= dwFileSizeHi;
4: bBuffer[0] = (BYTE)0x80;

then everything behaves as I want and I get correct values everywhere.

Why does the second version work and the first did not? Excuse me, if this is a newbie question.
Thank you in advance...

 

[Salem]

Very strange - I would have expected the first to work and the 2nd to fail for the reason you state.

Each type has an alignment restriction. Bytes for example can be stored at any address, but dwords for example typically have to be stored at an even address.

So whilst all dword pointers can be aligned byte pointers, the reverse is not necessarily true.



--

 

[Ewi]

Thank you for your answer.
IIRC I read about this alignment sometime. Perhaps I had luck and by coincidence the byte array is aligned to a suitable adress.

But the order is right; the second works, the first does not...

 

[zeitghost]

You could use a union.

It all comes out in the wash then.

(The FORTRAN EQUIVALENCE statement lives on!)

rgds
Zeit.

 

[Salem]

You would have to post small complete examples which we could look at and compile. I can't see anything else which would do as you suggest.

Besides, what you are attempting also depends on the endian-ess of the machine in question.

Assuming for a moment that you put say 0xAA as a byte in this code

DWORD dwBuffer[16];
PBYTE bBuffer = (BYTE *)dwBuffer;
bBuffer[0] = (BYTE)0x80;

Then dwBuffer[0] would be 0x80000000 on some machines, and 0x00000080 on other machines.


--

 

[Ewi]

Thank you, too.

I never worked with unions before. As far as I know one uses unions if it is necessary that a variable can be of different types, i.e. that 'number' is an int or a float. IIRC such a union variable is than int OR float and one can't access an int as float (as long as you don't cast it to be).

Correct me if I'm wrong; I would be happy to have this problem solved

 

[Ewi]

I put up the whole project (VS.NET 2003, code is completly in sha1.c, GUI is in resource.rc):

http://www.stw-bonn.de/~z25525/public/sha1.zip

It implements the SHA-1 algorithm.

The corresponding lines are in function OutSHA1Value (line 104 and line 134). If I comment out line 104 (correspond to version 2 above) and use line 106 (correspond to version 1 above), then the debugger stops in line 134 with an access violation.

The complete code is 223 lines (incl comments). Some comments are in german; please excuse me for that.

If you really want to look into it, would be VERY nice...

 

[zeitghost]

Hi.

Even with the union, the problem of byte ordering (endian) remains.

As Salem says above, what works with Intel won't work with other machines.

Though you could probably get a fix by using conditional compilation for different machines, it rapidly becomes a nightmare.

rgds
Zeit.

 

[Ewi]

I think I found the reason. Will report later, cause now I have to go.

Thank you...

 

[Salem]

>

http://www.stw-bonn.de/~z25525/public/sha1.zip

URL not found :-(

--

 

[Ewi]

Oh yes, I put it down after I found the bug. If you you want to I will put it up again...