-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Make deref_nullptr deny by default instead of warn #148122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
rustbot has assigned @petrochenkov. Use |
This comment has been minimized.
This comment has been minimized.
|
We discussed this in the lang meeting today. Everyone was in favour of moving it to deny, but we did discuss the fact that derefing a null pointer is no longer UB for a ZST pointee: https://doc.rust-lang.org/1.90.0/reference/behavior-considered-undefined.html#r-undefined.dangling.zero-size Thus we propose that this does go to deny, but with an additional update that it not lint if the pointee is known to be a ZST. (So not lint if it's @rfcbot fcp merge The other thing that came up, but is not part of the FCP, is that eventually the cases of reading a known ZST through a pointer might want a new warn (but not deny) lint about them in some form, perhaps suggesting https://doc.rust-lang.org/nightly/std/mem/fn.conjure_zst.html instead as the "blessed" way to create a ZST from nothing. But this PR wouldn't need to wait on having something to lint on the |
|
Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
|
@rfcbot reviewed |
|
@rfcbot reviewed |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
This lint was added 4 years ago in #83948 and I cannot find any discussion on that PR or its issue about whether it should be warn or deny by default.
I think keeping this lint to warn was at one point in the past justifiable because of the old bindgen behavior of generating tests that do null pointer derefs. I've certainly heard that argument. I don't think it holds up now, so I think we should be more firm about code that is definitely UB.
We merged #134424 which adds a runtime check for null pointer reads/writes, with very little fanfare. So now we know things like: This lint warns on 111 crates in crater, but 106 crates are encountering the runtime UB check. 65 crates hit both the lint and a runtime check. Of the 46 crates that only hit the lint, 25 look to me like machine-generated bindings, and all hits except https://github.com/Plecra/asm-w-ownership/blob/3a0eff4bd151d8a0ccc076d6b8dea0bbc051e8e8/src/main.rs#L454 are trying to compute a field offset, and should use
offset_of!.Based on the contents of the crater runs for 1.91, I'd expect these crates to go from test-fail to build-fail as a result of this change:
Most of the crates where the lint fires already don't build for other reasons (note there are a lot of C bindings wrapper crates in the set).