I didn't look in detail (I suspect the relevant details could be buried quite deep), but it looks likely to be a bug in Win32::API to me.
Even if not a bug in Win32::API, it looks like an uninitialized four-byte value is having only some of its bytes overwritten. So why not just work around it and pull out only the byte you care about?
$ret &= 0xFF;
Though, the return values you show actually show the lowest two bytes being consistently 0x7298, which seems rather unlikely.
printf "%d 0x%x\n", $_, $_ for 53113496, 52195992, 52851352, 52458136, 51540632 53113496 0x32a7298 52195992 0x31c7298 52851352 0x3267298 52458136 0x3207298 51540632 0x3127298
...So it could easily be neither of the things I guessed. Is 0x98 (152) the value you are expecting to get?
- tye
In reply to Re^3: How to use 'unsigned char' C data type with Win32::API (&255)
by tye
in thread Solved: How to use 'unsigned char' C data type with Win32::API
by sam_bakki
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |