[Issue 4887] Right-shifting by 32 is allowed and broken

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4887



--- Comment #6 from Stewart Gordon <smjg at iname.com> 2010-09-18 12:12:33 PDT ---
(In reply to comment #5)
> (In reply to comment #3)
> > http://www.digitalmars.com/d/1.0/expression.html#ShiftExpression
> > "It's illegal to shift by more bits than the size of the quantity being
> > shifted:
> > 
> > int c;
> > c << 33;    // error"
> > 
> > However, there's a real problem with that spec: what if the number of bits to
> > shift by isn't known at compile time?
> 
> That may be solvable with range propagation. Make it an error if it's not known
> to be less than 32. It'd be painful to completely implement that rule right
> now, but perhaps not later on when range propagation becomes more capable. We
> could at least make it an error if the range of the expression doesn't include
> ANY values in the legal range, and that would cover this test case.
> I suspect that shifts by runtime-determined numbers of bits are relatively rare
> -- and my experience is that they're quite bug-prone.
> 
> Raising priority to major, since this is a nasty trap.

But range propagation isn't going to be implemented in D1, or is it?

Trying it in 1.064 (Windows):

* (u)int << 32 or (u)int >> 32 is accepted by the compiler, but is a nop
* (u)int << 33 or (u)int >> 33 is rejected by the compiler, but if the 33 is
passed through a variable then it's equivalent to shifting by 1
* Shifting a (u)long by 32 or 33 seems to work, but the bug affects shifting
one by 64 or 65.

What is the "Other" platform for which this bug is filed?  (I'm guessing the
behaviour to be processor-dependent.  Mine, for the record, is a 2.4GHz Intel
Core Duo.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------