Figure out how to get rid of 'unsafe'.

[floooh]

The examples have quite a few unsafe in them. Would be nice if the sokol-bindings would allow to write code without usafe.

Maybe having separate internal C-compatible structs and public 'Rust-y' structs like I mentioned here (#6) could be the solution?

[EriKWDev]

Yes, there are some places where unsafe is needed currently.

The main one is whenever you want to convert a C-style pointer into a rust reference, we need to dereference it which in rust is unsafe for C pointers since they "could be null".

This includes *const sapp::EventType, *mut core::ffi::c_void userdata for all callbacks.

One thing I thogh about was making all the userdata related functions that return a *mut core::ffi::c_void instead be generic over a type T and return a mutable reference to that T.

This could look as such:

fn userdata<T>() -> &mut T {
    unsafe { std::mem::transmute(ffi::userdata() as *mut T) }
}


// At call-site no unsafe needed, just explicit type required 

let state: &mut MyStateStruct = sapp::userdata();

I'll have to think about if that transmute is valid. I'm not at a computer atm but I believe if we simply dereference the pointer and cast it normally to a reference we will get lifetime issues when we return it, but that might be incorrect.

The other places where unsafe is used are where I chose to use a global variable for the state instead of passing it as userdata. Getting a mutable reference to global data in Rust is considered unsafe always and is not related to the sokol bindings.

[floooh]

As a reminder, see comments here:

#26

...and here:

#30

...maybe the fix to avoid global state (and instead pass heap-allocated state into callbacks via the user_data pointer) can be wrapped in some sort of SokolApp helper "class" which contains the "unsafety".

[EriKWDev]

While I can see the desire to reduce the use of the unsafe keyword in user code, I personally am not a big fan of hiding it too much which is why I opted to the initial implementation.

What is being done here is by rusts definition unsafe since the compiler cannot guarantee the way the userdata was allocated when it comes back in the callbacks, but that is the exact thing the unsafe keyword is supposed to express.

One could expose some utilities

pub fn make_user_data<T>(data: T) -> *mut core::ffi::c_void {
    let allocation = Box::new(data);
    Box::leak(allocation) as *mut T as *mut core::ffi::c_void
}

pub fn user_data<T>(ptr: *mut core::ffi::c_void) -> &'static mut T {
    Box::leak(unsafe { Box::from_raw(ptr as *mut T) })
}

But then the user would still be the one who is required to uphold the rust safety guarantees, but now they just 'don't know' that it is unsafe.

The most rust way to do it would be to, as you say, write a helper thingy that simply gives the rust mutable reference to our state as a function argument and completely hides away that state is heap-allocated somewhere, but one could trivially build that on top of the current library, so if there is a need then someone should do it

The heap allocation is not a performance bottleneck, but is unnecessary and I personally would rather that my static global state is just that, a static global.