Incorrect PROC typedef

[msiglreith]

The definition of PROC causes issues on the latest nightly. The functions aren't allow to be zero, which rust makes use by annotating them with non-null. Unfortunately, the returned functions by wglGetProcAddress can be zero (e.g GL1.1 functions). Glutin currently checks if the functions are zero else it queries the addresses via kernel32::GetProcAddress. The rust compiler optimizes this call away as it assumes we don't have null functions.

The proposed solution is to replace extern "system" fn() with *const (), which also fixes the issue for me locally.

[tomaka]

The fix makes sense to me.

[brendanzab]

Yeah, as you can see from the comment I had no idea what I was doing when I was translating those type defs! What does PROC look like in use? Would people have to transmute/cast to *const ()?

I'm also guessing we would have to do a major release seeing as its an API change.

[retep998]

You can use what winapi does as an example of how it should be done. Raw pointer to an opaque type (can be replaced with extern type when that is stable enough).

https://github.com/retep998/winapi-rs/blob/b6eed13c28a8808bfdc54cdf50c4498132ce9176/src/shared/minwindef.rs#L76-L82

[brendanzab]

@retep998: That's still using a void enum - is it still UB to use that?

pub enum __some_function {}
/// Pointer to a function with unknown type signature.
pub type FARPROC = *mut __some_function;

cc. @eddyb

[brendanzab]

Wondering if we should just depend on winapi somehow for these types rather than having to maintain our own, but that's a separate issue 🤔

[eddyb]

The canonical equivalent for C function pointers into Rust is Option<extern fn()> (explicitly defined and whitelisted to do the right thing), and that is precisely what bindgen generates for them.

[retep998]

Raw pointers to uninhabited types are legal and well defined (because they can be created in safe code). You just can never ever deref it. All you have to do is transmute the raw pointer to Option<unsafe extern fn()> with the correct signature. The reason GetProcAddress returns a raw pointer to an uninhabited type instead of an Option<unsafe extern fn()> directly is because there is no fixed signature that the function pointers it returns will use. Otherwise someone could accidentally call the function pointer without first casting it to the correct type (which is bad).

[McGittyHub]

* friendly bump *

Any ETA on this?

[McGittyHub]

Is this going to be fixed any time soon?

Currently you cannot run release builds of programs using gl-rs on windows using current nightly rustc.

* yet another friendly bump *

[brendanzab]

Sorry for delays, gl_generator v0.7.0 and gl v0.7.0 should be published now with the fixes!

[albel727]

I've just encountered the very same typing bug resulting in segmentation fault due to __GLXextFuncPtr type in glx template, which is used as a return type for GetProcAddress().

gl-rs/gl_generator/generators/templates/types/glx.rs

Line 18 in dc92a66

pub type __GLXextFuncPtr = extern "system" fn();

Fixing the type fixes the crash for me.

[albel727]

So, it's been two weeks. Can we fix it for GLX too? Should I open a new issue?