Last time I struggled with 64 bit perls and this it was in the context of getting uint32 behaviour from pure perl in order to get Math::Random::MT::Perl working. With a little help from a generous monk this was duly solved with an & 0xffffffff to constrain the 64 bits to 32.

In the course of updating Digest::JHash (a fast 32 bit hashing algorithm) I have now struck the same problem, but this time from the C/XS side. The issue is that once you start hashing using left bitshifts on unexpectely 64 bit wide integers you blow out from 32 bits into the upper 32 bits which results in the behaviour commonly called "does not work (TM)" The problem per se is that I need a *reliable* *portable* uint32_t. Now <stdint.h>, <inttypes.h> and <sys/types.h> all define your basic uint32_t BUT using inconsistent names and with no guarantee of only 32 bits. I spent some time working with the author of Math::Random::MT trying to get a portable way of declaring a uint32_t that you can then be assured is exactly 32 bits - no more, no less. We were unable to find a really portable solution. <stdint.h> is not even included with VCC on MSWin32 - but its only be part of the standard since C99 ;-)

I struck me that I might be missing something obvious. The common thread across perls on many systems is of course perl. If for some reason there was a uint32 typdef lodged in the guts of perl I could just use that. The U32 type seems to fit the bill but will this be portable to 64 bit perls? From my reading the only guarantee is that it will be at least 32 bits wide. I really want exactly 32 bits.

Does anyone have a good solution to this problem?

If there is not a solid 32bit type then is was contemplating a macro that is a noop on 32 bit systems, or does & 0xfffffff on 64 bit systems. What is the best way of detecting a 64 bit perl, or more particularly an accidentally 64 bit wide uint32 in the context of a header if/else.