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
Like references, function pointers are, among other things, assumed to not be null, so if you want to pass a function pointer over FFI and be able to accommodate null pointers, make your type Option<fn()> with your required signature.
The comparison might simply never succeed. What was likely intended is to use the types Option<RespectiveFn> for the input argument, and not only for those stored. This might have been enver observed as a possible (and somewhat likely) likely compilation assigns the null pointer directly to the Option field, thus changing the discriminant to the intended None.
As also aluded to in the documentation, the correct type for ffi is also Option<fn(_) -> _ which should be reflected in the exposed C-interface here.
Also unfortunately, the liberal use of unsafe in the macro hides the fact that the assignment to the static mut ENVIRONMENT_CALLBACK is the one that is actuallyunsafe and strictly speaking would require a form of synchronization, such as using an AtomicPtr.
The text was updated successfully, but these errors were encountered:
An internal macro (
set_callback
) uses a transmute to create several different function types. This is UB and indicative of an underlying problem.libretro-backend/src/lib.rs
Lines 223 to 233 in 9248d74
According to the documentation of the function type:
The comparison might simply never succeed. What was likely intended is to use the types
Option<RespectiveFn>
for the input argument, and not only for those stored. This might have been enver observed as a possible (and somewhat likely) likely compilation assigns the null pointer directly to theOption
field, thus changing the discriminant to the intendedNone
.As also aluded to in the documentation, the correct type for ffi is also
Option<fn(_) -> _
which should be reflected in the exposed C-interface here.Also unfortunately, the liberal use of
unsafe
in the macro hides the fact that the assignment to thestatic mut ENVIRONMENT_CALLBACK
is the one that is actuallyunsafe
and strictly speaking would require a form of synchronization, such as using anAtomicPtr
.The text was updated successfully, but these errors were encountered: