Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: Perl XS portable uint32_t

by syphilis (Archbishop)
on Jun 06, 2008 at 14:15 UTC ( [id://690677]=note: print w/replies, xml ) Need Help??


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

The example you provided doesn't match what I'm finding with my 64-bit Microsoft Platform SDK for Windows Server 2003 R2 compiler on Vista 64. This compiler has 32-bit longs and ints - yet those high order bits are, I think, being lost to the "big bit bucket in the sky":
use warnings; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'EOC'; void foo() { unsigned long x = 0xffffffff; printf("long: %d\nint: %d\n", sizeof(long), sizeof(int)); printf("%x\n", x); x <<= 2; printf("%x\n", x); x >>= 2; printf("%x\n", x); } EOC foo(); __END__ Outputs: long: 4 int: 4 ffffffff fffffffc 3fffffff
Maybe this behaviour is not reliable across the full range of compilers/systems/architectures. (I honestly wouldn't know.)

Unfortunately you can't use sizeof in a preprocessor directive to do the setup one way on a 32 bit machine and another way on a 64 bit one

Yes - I was finding that out for myself (probably as you were writing your reply :-)

However, you can have the Makefile.PL query $Config{intsize} and $Config{longsize}. And the Makefile.PL can then define symbols (based on those config values) that the pre-processor can make use of.

Cheers,
Rob

Replies are listed 'Best First'.
Re^4: Perl XS portable uint32_t
by tachyon-II (Chaplain) on Jun 06, 2008 at 15:30 UTC

    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.....

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://690677]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (6)
As of 2024-04-20 02:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found