Atomic Types Challenge #82
Conversation
|
|
||
| In addition to any properties called out as SAFETY comments in the source code, all proofs must automatically ensure the absence of the following [undefined behaviors](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md): | ||
|
|
||
| * Data races. |
There was a problem hiding this comment.
Note that adding data races means that we cannot complete this challenge with Kani. I can take this out if we'd prefer to leave data races out of scope for this challenge. Not sure the feasibility of adding a tool later that can reason about this.
There was a problem hiding this comment.
The underlying CBMC supports concurrency, so perhaps Kani can do it?
There was a problem hiding this comment.
I think in principle we should keep this, since that is the main safety property of many safety guarantees offered by the type.
It's not clear to me what forms these proofs would take.
|
|
||
| In addition to any properties called out as SAFETY comments in the source code, all proofs must automatically ensure the absence of the following [undefined behaviors](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md): | ||
|
|
||
| * Data races. |
There was a problem hiding this comment.
The underlying CBMC supports concurrency, so perhaps Kani can do it?
There was a problem hiding this comment.
Thanks @carolynzech! Is there any usage of the unsafe functions in the standard library that is worth including in the challenge?
|
|
||
| In addition to any properties called out as SAFETY comments in the source code, all proofs must automatically ensure the absence of the following [undefined behaviors](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md): | ||
|
|
||
| * Data races. |
There was a problem hiding this comment.
I think in principle we should keep this, since that is the main safety property of many safety guarantees offered by the type.
It's not clear to me what forms these proofs would take.
| - `atomic_umax` | ||
| - `atomic_umin` | ||
|
|
||
| These functions are wrappers around compiler intrinsics. Thus, your task is to ensure that we cannot cause undefined behavior by invoking the intrinsics on these inputs. For instance, if the intrinsic takes as input a raw pointer and reads the value at that pointer, your contracts should ensure that we would not cause UB by performing the read. For the purpose of this challenge, you may assume that any UB in the intrinsics would be a direct consequence of malformed inputs. |
There was a problem hiding this comment.
Maybe this challenge should include writing contracts for those intrinsics and ensuring that the contracts are not violated by these methods.
There was a problem hiding this comment.
See comment. I can add intrinsics to this challenge as well, although we may want to be mindful of length. If we have contracts on the methods, intrinsics, and a meatier standard library application, this challenge will likely be the longest one we have. That's not necessarily bad, but I wonder if atomic intrinsics would be better as a separate challenge to keep the size of this one more manageable.
There was a problem hiding this comment.
Sure, but we still want to verify unsafe code inside safe functions, no?
Yes. I was erring on the side of keeping this challenge smaller, but there's some libraries that use more of the methods than |
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.