PeterRugg

It's true that revocation might get rid of them as a side effect, just from churning through the caches. It's not guaranteed though: the revocation sweep won't deliberately flush the...

Just noticed this as well. I also wonder about `cloadtags`. We really need to get stats on how much that matters with the load-side barrier, but in Cornucopia it looks...

Good questions! I'll have a go: > Is it legal to construct a zero-length capability with base = top != 0 (with CSETBOUNDS, etc)? Yes. Some codegen, e.g. structs with...

I'm a little confused... This issue is 2 years old, but seems to have a fix by me from 3 years ago... https://github.com/riscv/sail-riscv/pull/103. Anyway, testing now it seems to behave...

> we think the main issue is to prevent cases where the top overflows from allowing accesses to wrap the address space and allow access to byte 0, which the...

Given the strength of @jrtc27's last comment, I'll leave her to reply with how urgent this is. FWIW there doesn't seem to be any reason not to move to the...

Thank you both for the quick responses! I think what @Rewbert suggested could be the most pragmatic way forwards! The sad thing is that shrinking will likely change the behaviour...

@MaximilianAlgehed Good question. Thinking it through more, I think we'd need a variant of `Testable` with two type arguments, `ExtTestable prop disproof` (existing `Testable prop` would be `ExtTestable prop ()`),...

@nick8325 Indeed! That would get us somewhere. It's sad that it's happening twice, but maybe that's okay. In particular, in the worst cases for shrinking, you're trying lots of shrinks...

@nick8325 Thanks! That might be the way forward, and using unsafeIO probably gives us the way to do that in practice right now...