Max Orok

Hi! I think this would 100% take care of the plutonium issue. For functions like: ```rust #[safe] unsafe fn real_safe(x: f32) -> i32 { std::mem::transmute::(x) } #[safe] fn deref_null() {...

Hi @CQUswl, Could you post your egsinp as text in the comment body or upload the files themselves? It's much easier to start debugging if you don't have to manually...

Isn't that covered here by the acquire fence beforehand? Is it possible the actual variable access should use an atomic load? https://github.com/ringbahn/iou/blob/045f8d44c235e35b3731625356a11e6ee05966f9/src/submission_queue.rs#L158-L160

Right, that sounds like a good plan :)

> way for tests to receive which kernel they are testing under For future reference, two concrete ways to find the kernel version could be: https://docs.rs/nix/0.17.0/nix/sys/utsname/struct.UtsName.html https://docs.rs/cluuname/0.1.9/cluuname/fn.uname.html These are both...

I just revised the timeout test to use the `0.3` APIs.

Did you have something like this (naive impl) in mind? ```diff diff --git a/src/magazine.rs b/src/magazine.rs index 63c73c6..e99ba3e 100644 --- a/src/magazine.rs +++ b/src/magazine.rs @@ -398,7 +398,20 @@ impl crate::class::ClassInfo { if...

And I guess if there's a collision we could then fall back to a slower, fully accurate method to ensure there's no false positives overall.

Is there a potential issue here because allocations in a loop will be close together? Barring an issue with my quick implementation here, nearby allocations all get hashed with multiply-shift...

Closing in favour of a new RNTuple tutorial about merging as discussed with @jblomer.