-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible bitshifting footgun #21311
Comments
Afaik the arithmetic operators are defined in terms of values, regardless where they may come from, |
Closes ziglang#21311 The sign of the result `r` needs to be initialized before the correction `r.addScalar(r.toConst(), -1)`, or the intended end result could be off by 2 (depending on the original sign of `r`).
Closes ziglang#21311 The sign of the result `r` needs to be initialized before the correction `r.addScalar(r.toConst(), -1)`, or the intended end result could be off by 2 (depending on the original sign of `r`).
Just to confirm, is the result of the shift in the first test -2047 or -2046 for you? When I run the test, I get "expected -2048, found -2046", which aligns with the analysis of the fix in #21320 (off by 2). Currently, a release compiler reproduces this issue for me, while a debug compiler does not. With #21320 applied, the test also passes under a release compiler. (The difference between debug and release has to do with the Line 2779 in 3929cac
|
It looks like the behavior here is slightly different between
|
Ah, that makes sense, I only tested on master. The difference between 0.13 and master is most likely explained by the changes done in #20585 (which fixed an off-by-one error present before that change). |
Closes ziglang#21311 The sign of the result `r` needs to be initialized before the correction `r.addScalar(r.toConst(), -1)`, or the intended end result could be off by 2 (depending on the original sign of `r`).
Closes ziglang#21311 The sign of the result `r` needs to be initialized before the correction `r.addScalar(r.toConst(), -1)`, or the intended end result could be off by 2 (depending on the original sign of `r`).
Depending on whether
a
is modified or not (const
orvar
) the bitshift operator produces different results.Not sure if this could be regarded as a bug, but it does feel a bit dangerous
The text was updated successfully, but these errors were encountered: