digitalmars.D.learn - Bug in shifting
- Michelle Long (11/11) Dec 13 2018 byte x = 0xF;
- Daniel Kozak (6/17) Dec 13 2018 I do not understand you?
- Steven Schveighoffer (7/20) Dec 13 2018 Given that your code above doesn't compile, it's hard to figure out what...
- Jonathan M Davis (13/21) Dec 13 2018 Well, to be more precise, it doesn't allow fallthrough when the case
- Michelle Long (12/37) Dec 13 2018 I thought I had code in it which is what struct me as odd. There
- Rainer Schuetze (13/18) Dec 18 2018 It doesn't work as intuitive as you'd expect:
- Patrick Schluter (4/24) Dec 19 2018 Yes. On x86 shifting (x >> y) is in reality x >> (y & 0x1F) on 32
- Neia Neutuladh (12/15) Dec 13 2018 "Error: shift by 60 is outside the range 0..31"
byte x = 0xF; ulong y = x >> 60; Does not compute the proper value. It seems that the shift amount is wrapped. My code is more complex. The code above does give an error. I am using the code in a template. If I change x to ulong it works as expected. I've noticed the compiler is not throwing up errors and warnings like it used to: I thought D required breaks for cases? Seems it doesn't any longer! I'm only using -g -gf -d DMD64 D Compiler v2.083.0
Dec 13 2018
Daniel Kozak <kozzi11 gmail.com> I do not understand you? What is wrong? It works ok. https://run.dlang.io/is/ZFf0FQ What do you mean by D required breaks for cases? On Fri, Dec 14, 2018 at 1:20 AM Michelle Long via Digitalmars-d-learn < digitalmars-d-learn puremagic.com> wrote:byte x = 0xF; ulong y = x >> 60; Does not compute the proper value. It seems that the shift amount is wrapped. My code is more complex. The code above does give an error. I am using the code in a template. If I change x to ulong it works as expected. I've noticed the compiler is not throwing up errors and warnings like it used to: I thought D required breaks for cases? Seems it doesn't any longer! I'm only using -g -gf -d DMD64 D Compiler v2.083.0
Dec 13 2018
On 12/13/18 7:16 PM, Michelle Long wrote:byte x = 0xF; ulong y = x >> 60;Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.Does not compute the proper value. It seems that the shift amount is wrapped. My code is more complex. The code above does give an error. I am using the code in a template. If I change x to ulong it works as expected.Given that your code above doesn't compile, it's hard to figure out what you mean. Do you have a working example?I've noticed the compiler is not throwing up errors and warnings like it used to: I thought D required breaks for cases? Seems it doesn't any longer! I'm only using -g -gf -dIt doesn't require breaks for cases, it requires no fall-through on cases. Again, an example would help describe what you mean. -Steve
Dec 13 2018
On Thursday, December 13, 2018 6:56:33 PM MST Steven Schveighoffer via Digitalmars-d-learn wrote:On 12/13/18 7:16 PM, Michelle Long wrote:Well, to be more precise, it doesn't allow fallthrough when the case statement contains code. It will allow it when it doesn't. e.g. case 0: case 1: break; is perfectly legal. However, when the case statement contains code, then yeah, some form of control statement is required to exit the case statement, but that's a lot more than just break. continue, goto, return, etc. can all be used to exit a case statement. Any control statement that explicitly exits the case statement will work. And of course, goto case can be used for explicit fallthrough. - Jonathan M DavisI've noticed the compiler is not throwing up errors and warnings like it used to: I thought D required breaks for cases? Seems it doesn't any longer! I'm only using -g -gf -dIt doesn't require breaks for cases, it requires no fall-through on cases. Again, an example would help describe what you mean.
Dec 13 2018
On Friday, 14 December 2018 at 02:17:20 UTC, Jonathan M Davis wrote:On Thursday, December 13, 2018 6:56:33 PM MST Steven Schveighoffer via Digitalmars-d-learn wrote:I thought I had code in it which is what struct me as odd. There is a good chance I was wrong about this though since I was adding a bunch of case statements and code. Given that this occurred with the other problem might correlate to something else. Not that big a yet but the first struck me as a big problem if it is a bug... having code that should error but passes and provides wrong calculations is very prone to producing major bugs in a program. I don't feel like trying to reproduce them, but if they crop up again I'll try and catch them.On 12/13/18 7:16 PM, Michelle Long wrote:Well, to be more precise, it doesn't allow fallthrough when the case statement contains code. It will allow it when it doesn't. e.g. case 0: case 1: break; is perfectly legal. However, when the case statement contains code, then yeah, some form of control statement is required to exit the case statement, but that's a lot more than just break. continue, goto, return, etc. can all be used to exit a case statement. Any control statement that explicitly exits the case statement will work. And of course, goto case can be used for explicit fallthrough. - Jonathan M DavisI've noticed the compiler is not throwing up errors and warnings like it used to: I thought D required breaks for cases? Seems it doesn't any longer! I'm only using -g -gf -dIt doesn't require breaks for cases, it requires no fall-through on cases. Again, an example would help describe what you mean.
Dec 13 2018
On 14/12/2018 02:56, Steven Schveighoffer wrote:On 12/13/18 7:16 PM, Michelle Long wrote:It doesn't work as intuitive as you'd expect: void main() { int x = 256; int y = 36; int z = x >> y; writeln(z); } prints "16" without optimizations and "0" with optimizations. This happens for x86 architecture because the processor just uses the lower bits of the shift count. It is probably the reason why the language disallows shifting by more bits than the size of the operand.byte x = 0xF; ulong y = x >> 60;Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
Dec 18 2018
On Tuesday, 18 December 2018 at 20:33:43 UTC, Rainer Schuetze wrote:On 14/12/2018 02:56, Steven Schveighoffer wrote:Yes. On x86 shifting (x >> y) is in reality x >> (y & 0x1F) on 32 bits and x >> (y & 0x3F) on 64 bits.On 12/13/18 7:16 PM, Michelle Long wrote:It doesn't work as intuitive as you'd expect: void main() { int x = 256; int y = 36; int z = x >> y; writeln(z); } prints "16" without optimizations and "0" with optimizations. This happens for x86 architecture because the processor just uses the lower bits of the shift count. It is probably the reason why the language disallows shifting by more bits than the size of the operand.byte x = 0xF; ulong y = x >> 60;Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
Dec 19 2018
On Fri, 14 Dec 2018 00:16:51 +0000, Michelle Long wrote:byte x = 0xF; ulong y = x >> 60;"Error: shift by 60 is outside the range 0..31" This is the result of integer promotion rules. Change the 30 to a 60 and it works, and the result is, as you would expect, 0.I thought D required breaks for cases? Seems it doesn't any longer!A number of things can terminate a case block: * break * continue * goto * assert * throw * return Probably a few others.
Dec 13 2018