You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Return values from functions that contain 'static lifetimes are not reduced to the lifetime of the loaded library, and can outlive it.
Preventing this is probably impossible (especially when the 'static is hidden inside a type like Wrapper(&'static u32)), but the docs could warn about it.
Return values from functions that contain 'static lifetimes are not reduced to the lifetime of the loaded library, and can outlive it. Preventing this is probably impossible…
Indeed, I don’t see a way to prevent this, although this is not necessarily invalid (i.e. the value returned by a function is not necessarily 'lib. It might be worthwhile to mention this problem somewhere in the documentation.
I assume this issue also applies to loaded global variables, but dereferencing those produced bogus values even without dropping lib
Type of your Symbol is wrong here (lacking one level of indirection… it might be worthwhile to add a wrapper type for this on the libloading side…). But otherwise, yes, the problem is also present in this case.
This could be fixed by a smart wrapper type libloading::LibraryStatic*<u16>, but that definitely feels… inelegant.
I didn't realize variables must be loaded via a pointer type, although it makes sense with fn types being pointers under the hood.
With LibraryStatic, do you mean a completely different Library type for accessing statics, or a Symbol variant such as StaticSymbol?
I don't see how StaticSymbol could prevent getting a reference to the 'static reference in struct Wrapper(&'static u8), but it would fix #13 for variables and stop this from compiling:
Return values from functions that contain
'static
lifetimes are not reduced to the lifetime of the loaded library, and can outlive it.Preventing this is probably impossible (especially when the
'static
is hidden inside a type likeWrapper(&'static u32)
), but the docs could warn about it.Here's one example that segfaults:
Cargo.toml:
lib.rs:
main.rs:
I assume this issue also applies to loaded global variables, but dereferencing those produced bogus values even without dropping
lib
:lib.rs:
main.rs:
prints "variable: 27312 = 0x6ab0"
The text was updated successfully, but these errors were encountered: