Possibly-wrong alignment calculation in get_box_size #2699
Comments
|
It...looks right to me? But then I think I wrote it. This isn't actionable, I'm going to open a PR to remove the FIXME. |
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Apr 25, 2013
|
Fixed by 533425e |
pnkfelix
added a commit
to pnkfelix/rust
that referenced
this issue
Nov 22, 2013
I cannot tell whether the original comment was unsure about the arithmetic calculations, or if it was unsure about the assumptions being made about the alignment of the current allocation pointer. The arithmetic calculation looks fine to me, though. This technique is documented e.g. in Henry Warren's "Hacker's Delight" (section 3-1). (I am sure one can find it elsewhere too, its not an obscure property.)
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this issue
Dec 3, 2022
refactor scheduler Refactors the scheduler to use something akin to a generator -- a callback that will be invoked when the stack of a thread is empty, which has the chance to push a new stack frame or do other things and then indicates whether this thread is done, or should be scheduled again. (Unfortunately I think we [cannot use actual generators](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Generators.20that.20borrow.20on.20each.20resume.3F) here.) The interpreter loop is now a proper infinite loop, the only way to leave it is for some kind of interrupt to be triggered (represented as `InterpError`) -- unifying how we handle 'exit when calling `process::exit`' and 'exit when main thread quits'. The last commit implements an alternative approach to rust-lang/miri#2660 using this new structure. Fixes rust-lang/miri#2629.
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this issue
Jan 6, 2023
refactor scheduler Refactors the scheduler to use something akin to a generator -- a callback that will be invoked when the stack of a thread is empty, which has the chance to push a new stack frame or do other things and then indicates whether this thread is done, or should be scheduled again. (Unfortunately I think we [cannot use actual generators](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Generators.20that.20borrow.20on.20each.20resume.3F) here.) The interpreter loop is now a proper infinite loop, the only way to leave it is for some kind of interrupt to be triggered (represented as `InterpError`) -- unifying how we handle 'exit when calling `process::exit`' and 'exit when main thread quits'. The last commit implements an alternative approach to rust-lang/miri#2660 using this new structure. Fixes rust-lang/miri#2629.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Per fixme in rust_util.h.
The text was updated successfully, but these errors were encountered: