const in a Function that Writes to Memory #143
Unanswered
Jimmycreative
asked this question in
Q&A
Replies: 1 comment 5 replies
-
Hi @Jimmycreative. I'm unable to reproduce the same error. I'm getting a different error:
Can you post the full log of the run including the command? It would also help to push the changes to your fork and provide a link to it. |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am attempting to write a contract for the NonNull::write function. The write function is designed to overwrite a memory location with a new value without reading or dropping the old value. Here's the function signature:
Issue Encountered
The primary issue I am facing relates to the use of the const qualifier on the write function and the attempt to use Kani's ensures condition to verify that the value at the pointer has been updated correctly.
Specifically:
The function does not read or drop the old value before writing, and this is by design. This means that we should not rely on reading the value to verify correctness, as this would contradict the stated behavior of write.
When attempting to add an ensures postcondition, such as:
#[ensures(|_| unsafe { *self.as_ptr() == val })]
I encountered the error:
"pub const unsafe fn write(self, val: T)
| ^^^ the destructor for this type cannot be evaluated in constant functions" or "consider further restricting this bound" error.
const fn
cannot evaluate destructors, and Rust cannot guarantee thatT
is a trivial type without destructors. This is why a postcondition involving*self.as_ptr() == val
leads to a compilation error.Why This is Problematic
write
function isconst
, meaning that it must be able to be evaluated at compile time. However, ifT
has a destructor, this destructor cannot be evaluated in aconst
context. This is what leads to the error when trying to verify the value using*self.as_ptr() == val
.write
explicitly states that the function will not read the old value or drop it. This implies that any verification relying on reading the value might contradict the intended behavior and result in undefined or incorrect usage.Questions for Discussion
write
operation without reading the value in a way that respects the function's intended behavior?write
operation inconst
contexts, especially for generic types where destructors may be involved?Beta Was this translation helpful? Give feedback.
All reactions