in reply to Re^3: Perl XS portable uint32_t
in thread Perl XS portable uint32_t

Ah this just demonstrates the bit loss. Here is an example using 2 different width ints:

use Inline C => <<'EOC'; void poo () { unsigned short s = 0xffff; unsigned long l = (unsigned long) s; printf("short %08x\n long %08x\n", sizeof(s), sizeof(l)); printf("short %08x\n long %08x\n", s, l); s <<= 4; l <<= 4; printf("short %08x\n long %08x\n", s, l); s >>= 4; l >>= 4; printf("short %08x\n long %08x\n", s, l); if ( l != (unsigned long) s ) printf("Bugger!\nerror %08x\n", l^(unsigned long)s ); } EOC poo(); __END__ short 00000002 long 00000004 short 0000ffff long 0000ffff short 0000fff0 long 000ffff0 short 00000fff long 0000ffff Bugger! error 0000f000

This is exactly what happens if you think you have a 32 bit int but actually have a 64 bit int. 2 operations and the results now differ.....

Replies are listed 'Best First'.
Re^5: Perl XS portable uint32_t
by syphilis (Archbishop) on Jun 06, 2008 at 22:30 UTC
    This is exactly what happens if you think you have a 32 bit int but actually have a 64 bit int

    Yes - which demonstrates that you need to know what you have. I'm in agreement with that - and have been right from the beginning. It's just that I don't see a need to establish anything other than that wrt Digest::JHash. And, given that that info can easily be derived by (or passed to) the pre-processor, you can tailor jhash() to efficiently deal with any scenario.

    But maybe I'm being blind to certain issues ... so I'll just butt out. I look forward to the next release of Digest::JHash, where I get to see how you eventually do deal with the issue :-)

    Cheers,
    Rob