On Wed, Jul 20, 2005 at 05:56:12AM -0700, Steve Peters via RT wrote:
> > Resubmitting a bug report of mine back from February;
> > this time through the proper channel (perlbug, not p5p).
> >
> > [paste]
> >
> > While editing my Damn Book I re-remembered that couple of months back
> > I ran into an anomaly in the handling of bitvectors.
> >
> > Fiction: you have a bitvector which you want to shift.
> >
> > The current (5.005_03-MT5) fact:
> >
> > perl -wle '$b = ""; vec($b, 0, 1) = 1;print unpack("b*",
> > $b);$b<<=1;print unpack("b*", $b)'
> > 10000000
> > 00001100
> >
> > Huh? Adding -w tells more, as usual:
> > Argument "^A" isn't numeric in left_shift at -e line 1.
> >
> > So left_shift assumes that the argument to shift is a number, but "^A"
> > isn't, so it gets converted to string zero "0" (48, 0x30, 0b0000110).
> >
> > I consider this behaviour to be rather broken. I think
> >
> > $b <<= 1
> >
> > should shift the whole bitvector left by one position and
> >
> > vec($b, 2, 8) >>= 2
> >
> > should shift the bits 16..23 right by two positions (of course not
> > leaking into bits 8..15).
> >
>
> Just so we're clear, and to add a proper TODO test case, what would you
> consider the proper output to be?
I am opposed to such a change in behaviour.
<<= operates on numeric values, while vec operates on strings.
vec($b,0,1) = 1
is just the same as
$b = "\x0\x0\x0\x01"
(ignoring endianess and int size complications)
If the << and >> operators were to take any string as a bit pattern, then
it would break code like:
$b="1"; $b <<= 2; print $b
which should print 4, not "\xc4".
--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
-- Things That Never Happen in "Star Trek" #10
