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

Fixed length array type with negative count is accepted #15917

Closed
lilyball opened this issue Jul 23, 2014 · 10 comments
Closed

Fixed length array type with negative count is accepted #15917

lilyball opened this issue Jul 23, 2014 · 10 comments

Comments

@lilyball
Copy link
Contributor

A fixed length array type is allowed to be declared with a negative count. This is interpreted as the uint that would result from coercion, so on a 64-bit machine, [uint, ..-1] is considered the same as [uint, ..18446744073709551615].

This should probably be a compiler error, as negative counts don't make sense. Negative repeat counts in array expressions are already disallowed (as of #6985).

@Gankra
Copy link
Contributor

Gankra commented Jul 23, 2014

Possibly another face of #5477?

@lilyball
Copy link
Contributor Author

@gankro Nope. Fixed length array types actually explicitly allow for the length to be an int literal. The bug is just that it doesn't bother ensuring it's non-negative. Unlike #5477, this really is something that should be a hard compiler error.

@hirschenberger
Copy link
Contributor

Can be easily fixed after #15709 landed

@lilyball
Copy link
Contributor Author

@hirschenberger I don't think #15709 is related. The issue here isn't an undetected overflow. The issue is it blindly accepts int expressions without testing if the value is non-negative.

@hirschenberger
Copy link
Contributor

@kballard The size of the Array is parsed here as an int because there's no suffix:

https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/parser.rs#L2038

So the overflow already happened. With #15709 we get the chance, to check for negative literals and also got the full u64 range for the size although it is an int.

@lilyball
Copy link
Contributor Author

@hirschenberger It's parsed as an int, yes. An int with the value -1. The problem lies in https://github.com/rust-lang/rust/blob/master/src/librustc/middle/typeck/astconv.rs#L883-L885 where it doesn't bother checking if the int is non-negative before casting it to a uint.

@hirschenberger
Copy link
Contributor

I think this can be closed now.

@lilyball
Copy link
Contributor Author

Nope, still reproduces. Your test actually tests constructing a value. But the type expression [uint, ..-1] itself is still accepted and behaves incredibly badly. On latest master (which includes your test and the fix from #15709), the following program sucks up 100% CPU and gobbles up memory like candy (I had to kill rustc when it crossed 14GB RSIZE in 20 seconds):

fn main() {
    let x: [uint, ..-1];
}

@hirschenberger
Copy link
Contributor

@kballard sorry, I totally oversaw that this issue is about a type declaration, not a value.

@thestinger
Copy link
Contributor

Rust doesn't actually have - in the grammar for literals. The expression -1 is a generic integer and is inferred as uint in this context. The uint type does provide an - operator and it behaves as expected. It's the same issue as #15918.

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 27, 2023
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

4 participants