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

No check for infinitely sized structs #3779

Closed
nikomatsakis opened this issue Oct 16, 2012 · 7 comments · Fixed by #11839
Closed

No check for infinitely sized structs #3779

nikomatsakis opened this issue Oct 16, 2012 · 7 comments · Fixed by #11839
Labels
A-codegen Area: Code generation P-medium Medium priority
Milestone

Comments

@nikomatsakis
Copy link
Contributor

The following program causes a stack overflow:

struct S {
    element: Option<S>
}

fn main() {
}

There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)

@bblum
Copy link
Contributor

bblum commented Oct 19, 2012

Huh, so that's why std::list has pointer indirections in it.

@Aatch
Copy link
Contributor

Aatch commented May 21, 2013

This is still an issue, nominating for production ready

@graydon
Copy link
Contributor

graydon commented Jul 11, 2013

accepted for production-ready milestone

@emberian
Copy link
Member

So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.

@bblum
Copy link
Contributor

bblum commented Jul 13, 2013

@cmr you have to reference the type, just like #5146, which I triaged today. Actually I think they are the same bug.

@huonw
Copy link
Member

huonw commented Jan 19, 2014

This applies to non-infinite-sized types that contain themselves unboxed like the following too:

struct Foo { x: [Foo, .. 0] } // possibly ok, size is 0.

@pnkfelix
Copy link
Member

Accepted for 1.0, P-high.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Oct 27, 2024
Replace set_last_error with set_last_error_and_return

Took care of the simple patterns. Other patterns involved setting an error and then using `write_int` or setting metadata and returning -1. Unsure if those are in the scope of this change

Looks like this has conflicts with rust-lang#3779, so I can update when how to handle that is decided.

Part of rust-lang/miri#3930.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation P-medium Medium priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants