in reply to More 64-bit Perl bugs?

Other workarounds for the vec > 2**31 offsets bug?

My crude approach to extending the addressable bit range to 2**32-1 would be to divide the offset by 2 and operate in units of 2 bits. Something like this:

sub setbit { # args: var, offset, value (0/1) if ($_[1] % 2) { # odd offset if ($_[2]) { vec($_[0], $_[1]/2, 2) |= 0b10; # set } else { vec($_[0], $_[1]/2, 2) &= 1; # clear } } else { # even offset if ($_[2]) { vec($_[0], $_[1]/2, 2) |= 1; # set } else { vec($_[0], $_[1]/2, 2) &= 0b10; # clear } } } my $v = ""; setbit($v, 2**32-1, 1); # set bit setbit($v, 2**32-1, 0); # clear bit

(and likewise for reading a bit)

The idea could in principle be extended to other unit sizes (4, 8, ...), though the bit fiddling would then be somewhat more involved.

Replies are listed 'Best First'.
Re^2: More 64-bit Perl bugs?
by BrowserUk (Patriarch) on Mar 14, 2012 at 21:36 UTC

    That's a neat, 'sideways-look' solution to the problem.

    Except that I need to allocate > 4GB which means it'd just move the goalposts.

    I agree that by moving to (say) 8-bit unit size, would get me to 16 GB, but my target is 64 GB, which would require 10 bits, which means moveing to 16-bit unit size. At that point, I'd probably be better off treating the vector as an array of 64-bit units.

    The big loss is the convenience of the lvalue sub.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?