Comment #0 by matti.niemenmaa+dbugzilla — 2006-11-18T06:06:30Z
The compiler allows the following code, directly from the spec:
int c;
c << 33; // error
Even though "[i]t's illegal to shift by more bits than the size of the quantity being shifted". I'm not sure if this is a useful restriction, but either the spec or DMD is in error.
Comment #1 by smjg — 2006-11-18T07:02:01Z
If the right operand is a variable, it probably makes more sense from an efficiency POV to allow it. If it's a compile-time constant, the compiler could easily catch the error. However, I'm beginning to think such a restriction may interfere with generic programming.
Comment #2 by matti.niemenmaa+dbugzilla — 2006-12-03T03:36:35Z
Only partially fixed in DMD 0.176. Stepping up the priority since compiler behaviour is now inconsistent.
void main() {
int c;
c = c << 33; // Error: shift left by 33 exceeds 32
}
void main() {
int c;
c = c >> 33; // Works, shouldn't
}
void main() {
int c;
c <<= 33; // Works, shouldn't
}
void main() {
int c;
c >>= 33; // Works, shouldn't
}
void main() {
int c;
c = c >>> 33; // Works, shouldn't
}
void main() {
int c;
c >>>= 33; // Works, shouldn't
}
Also, this error message seems a bit strange:
void main() {
int c;
c = c << -1; // Error: shift left by -1 exceeds 32
}
Comment #3 by matti.niemenmaa+dbugzilla — 2007-05-12T03:04:27Z
Though the spec doesn't say it, it might as well be worth also disallowing shifts equal to the size of the quantity, as they just zero the value.
Or, at least, they should: some appear to be no-ops currently. As pointed out by Thomas Kühne in digitalmars.D.learn ( http://lists.puremagic.com/pipermail/digitalmars-d-learn/2007-May/005040.html ), compile-time shifts should be done by ((shift >= x.sizeof * 8) ? 0 : shift) instead of the current (shift % (x.sizeof * 8)).
Comment #4 by matti.niemenmaa+dbugzilla — 2007-10-05T14:29:23Z
DMD 1.022 fixes the issues, but the error messages for the shift expressions (e.g. c = c << 33) don't have file and line number info. The assignments (c <<= 33) do, though.
Comment #5 by braddr — 2007-10-20T03:05:23Z
Per Walter's request, moving the new problem (missing line numbers) into a new bug. This one has been addressed. A little counter intuitively, the source of the two issues is probably not actually related to the same part of the code.