Conversions in C
-
Hi I am wondering if anyone can point me in the right direction I am getting strange results When I try to move a DWORD to a char[4] I am running in 64 bit mode and it my understanding that both are 32 bits long The DWORD has 4 bytes of a ebcdic character string I want to move the DWORD to char 4 so that I can access every character and convert it to ascii when I try to move 1 of the chars to a unsigned int e.g. Unsigned int c = str[1] the result in c is a negative number maybe the high order bit in str[1] byte is on but by moving it to a unsigned int shouldn't that do away with making the result negative for example moving a D0 results in FFF2 Any help appreciated Thanks
-
Hi I am wondering if anyone can point me in the right direction I am getting strange results When I try to move a DWORD to a char[4] I am running in 64 bit mode and it my understanding that both are 32 bits long The DWORD has 4 bytes of a ebcdic character string I want to move the DWORD to char 4 so that I can access every character and convert it to ascii when I try to move 1 of the chars to a unsigned int e.g. Unsigned int c = str[1] the result in c is a negative number maybe the high order bit in str[1] byte is on but by moving it to a unsigned int shouldn't that do away with making the result negative for example moving a D0 results in FFF2 Any help appreciated Thanks
I think the problem comes from the way bytes are ordered in memory. When you treat a 4-byte block as a DWORD, the bytes are not in order from MSB to LSB. It depends upon your hardware. You can verify this in the debugger. Place a breakpoint anywhere you are using the DWORD variable, and then when it breaks, switch to Disassembly view. (Make sure "Show code bytes" is on.) You'll see the way the bytes are ordered, and it's not what you expect!
The difficult we do right away... ...the impossible takes slightly longer.
-
I think the problem comes from the way bytes are ordered in memory. When you treat a 4-byte block as a DWORD, the bytes are not in order from MSB to LSB. It depends upon your hardware. You can verify this in the debugger. Place a breakpoint anywhere you are using the DWORD variable, and then when it breaks, switch to Disassembly view. (Make sure "Show code bytes" is on.) You'll see the way the bytes are ordered, and it's not what you expect!
The difficult we do right away... ...the impossible takes slightly longer.
-
Hi I am wondering if anyone can point me in the right direction I am getting strange results When I try to move a DWORD to a char[4] I am running in 64 bit mode and it my understanding that both are 32 bits long The DWORD has 4 bytes of a ebcdic character string I want to move the DWORD to char 4 so that I can access every character and convert it to ascii when I try to move 1 of the chars to a unsigned int e.g. Unsigned int c = str[1] the result in c is a negative number maybe the high order bit in str[1] byte is on but by moving it to a unsigned int shouldn't that do away with making the result negative for example moving a D0 results in FFF2 Any help appreciated Thanks
In this case we have to implement an algorithm for packing 4 bytes to a single dword programmatically. Also, there's no default conversion. DWORD data type is 32 bits = 4 bytes long regardless of it's x64 or x86 mode. :)
-
In this case we have to implement an algorithm for packing 4 bytes to a single dword programmatically. Also, there's no default conversion. DWORD data type is 32 bits = 4 bytes long regardless of it's x64 or x86 mode. :)
Hercules has a function FETCH_FW which will take a MainFrame fullword 4 bytes and put in the right sequence for Windows/Linux However it is still coming in EBCDIC and I need to convert it to ASCII thus I need to access every byte and convert it the function FETCH_FW takes as 1st param a DWORD I thought using unsigned char[4] would produce the same result apparently not
