-
Notifications
You must be signed in to change notification settings - Fork 746
Make it possible so that function pointers aren't always wrapped in an Option. #1278
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
Comments
What's so bad about calling |
|
Well, if you do care about the instruction count I guess that you can unsafely match / transmute, like: #[macro_use] extern crate debug_unreachable;
match my_func {
Some(f) => f,
None => debug_unreachable!(),
}; But yeah, I agree. Generally we've supported field annotations via doc comments, but if you're using a library that may not be a great solution. For C this is easy-ish to map to a struct + name, for C++.. not so much I guess. I can mentor this if you want, I don't know if a |
Thank for the offer to mentor. If I wasn't so snowed under with work I'd love to take up your offer. I make extensive use of bindgen in my projects and would love to get some changes to make it easier in my workflow. |
I'd like this not for some performance reason but so that I could declare function pointers for initializing a struct of function pointers which are guaranteed not to be null. The option wrapped version makes this impossible. This is a useful pattern when loading dynamic libraries rather than linking against a library at compile time. |
If the functions are marked with |
Function pointer tables occur every now and then in C libraries, however "nonnull" attributes seem to be extremely rare, meaning a decision based solely on them is likely ineffective for a large part of the C ecosystem. An example I currently face: Godot's GDExtension binding. A big There are workarounds like macros based on |
If you don't mind recompiling bindgen, you can tweak the code yourself. The code that wraps function types in
Modify it to:
Now run Dealing with unsafe code is now entirely your responsibility. But I'd wish to have a switchable option for bindgen to toggle this feature. This will help while dealing with structs with function type members, used mainly for callbacks. |
I would love this feature too - for now, I'm going to utilize the recompiled version with the change above, but having some option to switch it could be very handy. |
As @emilio mentioned there are two possible APIs for this:
Not sure what's better to be honest. |
I might have hit a use case where this option would be essential, although please correct me if I’m wrong. I’m trying to use bindgen on the Vulkan headers. In general the Vulkan API is accessed almost entirely through function pointers because most entry points are only optionally implemented in the driver so you have to check for the extension that provides the functionality before getting the function pointer and calling the function. The functions to get access to the function pointers look like this: VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL vkGetDeviceProcAddr(
VkDevice device,
const char* pName); So you pass the name of the function you want and then it returns a pointer to a function with no arguments and a void return type. You are then expected to cast it to the right function type. The header also includes a typedef for each possible function that the driver could provide like this: typedef void (VKAPI_PTR *PFN_vkCmdDraw)(VkCommandBuffer commandBuffer,
uint32_t vertexCount,
uint32_t instanceCount,
uint32_t firstVertex,
uint32_t firstInstance); In C this is quite convenient because you can just cast it via void* like this: PFN_vkCmdDraw cmd_draw = (void *) vkGetDeviceProcAddr(device, "vkCmdDraw");
cmd_draw(3, 1, 0, 0); With the rust bindings generated by bindgen the |
If you statically that the type is never Another option is just a simple |
I'm working on bindings of a C library (OpenUCX) where the majority, but not all, of function pointers used are never null (both typedefs and struct fields) - hence they shouldn't be generated as
Option<extern fn ...>
but asextern fn ...
. A very small number, however, can be null, and so needs to stay asOption<extern fn ..>
. It'd be nice to do this via bindgen. Currently I post-process them usingbindgen-wrapper
(a horribly brittle tool of my own devising).Would it possible for bindgen to take a list to override this behaviour, of structs and typedefs?
The text was updated successfully, but these errors were encountered: