dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Clarify about fixing LLVM despite C 

Even if the C standard allows for what LLVM is doing, we could still
conceivably fix LLVM.  In the text, let's draw this out a bit more
finely.

(Thanks to RalfJ for raising this point.)
This commit is contained in:
Travis Cross 2024-05-07 15:38:57 +00:00
parent ca7713cba6
commit efc671cf08
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
text/0000-unsafe-extern-blocks.md
View File

@ -148,9 +148,9 @@ One could ask, why not fix LLVM such that incorrect signatures in an `extern` bl
There are three problems with this.
One, it's not entirely clear that it's feasible to fix LLVM in this way. Moreover, it's still a bit unclear to us whether or not this behavior is allowed by the C standard. If it is allowed, then LLVM does not, arguably, need to be fixed at all.
One, it's not entirely clear that it's feasible to fix LLVM in this way. Moreover, it's still a bit unclear to us whether or not this behavior is allowed by the C standard. If it is allowed, that may make it more challenging to build a consensus in favor of changing it in LLVM.
Two, even if the C standard does not permit what LLVM is doing and it proves feasible to fix LLVM, we still, as described above, believe that it's unreasonable to expect that *callers* to a function declared in an `extern` block should have to prove that the signature is correct. We want the obligation of proving this to sit with the person writing the `extern` block, not the person calling a function declared within.
Two, even if the C standard does not permit what LLVM is doing (or we were otherwise able to build a consensus for change) and it proves feasible to fix LLVM, we still, as described above, believe that it's unreasonable to expect that *callers* to a function declared in an `extern` block should have to prove that the signature is correct. We want the obligation of proving this to sit with the person writing the `extern` block, not the person calling a function declared within.
Three, if we were to say that the proof obligation of ensuring the signature of an item declared within an `extern` block rests with the person *using* that item, then we could never declare some items within an `extern` to be OK to use directly from safe code. This is something we want to allow, and the only way to do this is if the proof obligation rests with the person writing the `extern` block. Marking these blocks with `unsafe` more clearly signals who holds this proof obligation.