Skip to content
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

i8 literals and friends have incorrect ranges #2438

Closed
bstrie opened this issue May 24, 2012 · 10 comments
Closed

i8 literals and friends have incorrect ranges #2438

bstrie opened this issue May 24, 2012 · 10 comments

Comments

@bstrie
Copy link
Contributor

bstrie commented May 24, 2012

https://gist.github.com/2783543

The maximum legal value of signed integers of length x should be (2^(x-1)) - 1, but in most cases Rust allows signed literals of value 2^(x-1), but then interprets those literals as the minimum legal value (see the output in the gist above).

The exception is i16, which exhibits the same behavior as above, except that, bafflingly, x is 12 rather than 16.

EDIT: wrong equations

@msullivan
Copy link
Contributor

The test case for i16 is "log(error, 2048i16);", so it isn't too surprising that it prints 2048...

@bstrie
Copy link
Contributor Author

bstrie commented May 25, 2012

@msullivan Yes, the point is that log(error, 2049i16); fails with a literal out of range error. :)

@msullivan
Copy link
Contributor

Ah. So yeah, that is just a straight up bug. I can fix it.

The other part is trickier: I think rust only considers positive literals, and when you write a negative number it is parsed as negation applied to a positive number. This means that if we had the proper positive bound on numbers, you wouldn't be able to write things like "-128i8"...

Argh.

@bstrie
Copy link
Contributor Author

bstrie commented May 26, 2012

I don't think you need to mess with the parser, as long as the bounds check can be moved to after the negation is applied to the literal.

@msullivan
Copy link
Contributor

I'm splitting the i16 part off into Issue #2462. This bug then is just the maximum value problem.

@bstrie
Copy link
Contributor Author

bstrie commented May 30, 2012

Some more weirdness, for your perusal: using 128i8 to successfully index an array.

fn main() {
    let mut bar = [mut 0];
    vec::grow(bar, 128u, 0);
    bar[128] = 1;
    log(error, bar[128i8]);  // prints 1
}

@msullivan
Copy link
Contributor

Split that last part into #2468

@catamorphism
Copy link
Contributor

@msullivan or @bstrie -- could you clarify which part of this issue is still open?

@bstrie
Copy link
Contributor Author

bstrie commented Nov 12, 2012

@catamorphism It depends on if you consider it a bug that the literal 128i8 is perfectly valid, despite the fact that i8 is within the range [-128, 127]. I just checked, and it's still the case that 128i8 is interpreted as -128.

@bstrie
Copy link
Contributor Author

bstrie commented Jun 5, 2013

The more immediate problem was fixed, closing this in favor of #6958.

@bstrie bstrie closed this as completed Jun 5, 2013
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
adjust for more backtrace pruning

The Miri side of rust-lang#99690. Those messages are much nicer. :) And we also need error-pattern much less.
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
We don't need name demangling since we store the mangled and pretty name of harnesses in the metadata file. I also updated the comment in the `symbol_name` function.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants