-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking issue for safe_extern_statics
compatibility lint
#36247
Comments
In the case where I'm using an Example:
One option I've considered is to always allocate two statics, one |
@cbiffle |
@petrochenkov, yes, that is basically what I'm hoping for. Just as I can use Does it already exist? (I'm trying to get code working today.) |
No. Even if someone submits an RFC right now, it'll be months until it's accepted (if it's accepted), implemented and hits stable. A worse advice is to use |
This fixes safe_extern_statics warnings; see <rust-lang/rust#36247>.
Wrap uses of extern statics in unsafe blocks. This fixes safe_extern_statics warnings; see <rust-lang/rust#36247>. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-mozjs/307) <!-- Reviewable:end -->
This is required now due to rust-lang/rust#36247.
cc @rust-lang/lang So I had a long conversation with @wycats about this. He convinced me that simply declaring all accesses to statics as unsafe is not an optimal solution. Specifically, it is common in C code to have statics that are constant (never mutated), and right now there is no way to "wrap" those statics with a safe interface. To see what I mean, consider wrapping a C function mod sys {
extern { fn noop(); }
}
fn noop() {
// I assert that this is safe to call at any time
unsafe { noop(); }
} This is annoying, but mostly works. On the other hand, if I have a static constant, I am stuck. An example is that Ruby has a constant for a nil value, called I see two possible solutions here: Define some way for FFI declarations in general to declare that the value is, in fact, safe. this could also be used to wrap Permit Regardles, we should probably handle this case more nicely I think! |
Er, I'm actually just repeating what @cbiffle wrote, I suppose. =) Sorry, missed those comments. |
@nikomatsakis |
Are we disallowing |
@petrochenkov I am indeed =) I'm always like 2 steps behind on the RFC repo...working on catching up though! |
@eddyb indeed that's a nifty thought, although it means users will have to write |
@nikomatsakis While |
Const has some additional semantics over static, such as the ability to use it in patterns. Would extern consts also gain these semantics? (I'm opposed either way) |
I think |
This fixes safe_extern_statics warnings; see <rust-lang/rust#36247>.
- New allocator API - Remove the "allocator" feature, which should be unnecessary due to how the new allocator API works - NonZero no longer implements Deref (rust-lang/rust#41064) - NonZero::new() returns an Option; use NonZero::new_unchecked() - Thread locals are no longer 'static (rust-lang/rust#43746) - Changes to feature flags - Use unsafe to access extern static (rust-lang/rust#36247)
This fixes safe_extern_statics warnings; see <rust-lang/rust#36247>.
@joshtriplett what's to be done here? |
Transition some C-future-compatibility lints to {ERROR, DENY} Closes #40107 (ERROR). Closes #39207 (ERROR). Closes #37872 (ERROR). Closes #36887 (ERROR). Closes #36247 (ERROR. Closes #42238 (ERROR). Transitions #59014 (DENY). Transitions #57571 (DENY). Closes #60210 (ERROR). Transitions #35203 (DENY). r? @petrochenkov
Transition future compat lints to {ERROR, DENY} - Take 2 Follow up to rust-lang#63247 implementing rust-lang#63247 (comment). - `legacy_ctor_visibility` (ERROR) -- closes rust-lang#39207 - `legacy_directory_ownership` (ERROR) -- closes rust-lang#37872 - `safe_extern_static` (ERROR) -- closes rust-lang#36247 - `parenthesized_params_in_types_and_modules` (ERROR) -- closes rust-lang#42238 - `duplicate_macro_exports` (ERROR) - `nested_impl_trait` (ERROR) -- closes rust-lang#59014 - `ill_formed_attribute_input` (DENY) -- transitions rust-lang#57571 - `patterns_in_fns_without_body` (DENY) -- transitions rust-lang#35203 r? @varkor cc @petrochenkov
What is this lint about
Consider the following code:
S
here is a static variable accessible to Rust but defined and initialized elsewhere.External static variables cannot be accessed safely from Rust code for several reasons:
S
can contain an arbitrary bit pattern not necessarily being a valid value of typeT
.T
,S
is still not controlled by Rust ownership system and can be accessed from other threads potentially creating data races.See #35112 for more details as well as examples of how this can lead to crashes.
Previously safe accesses to extern statics were erroneously permitted outside of unsafe blocks. #36173 fixed this oversight.
How to fix this warning/error
Surround accesses to extern statics with
unsafe
blocks and make sure these accesses are actually valid.Current status
safe_extern_statics
lint as warn-by-defaultsafe_extern_statics
lint deny-by-defaultsafe_extern_statics
lint a hard errorThe text was updated successfully, but these errors were encountered: