-
Notifications
You must be signed in to change notification settings - Fork 700
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
Feature request: Customize pointer types #2023
Comments
Not opposed to this, seems like a reasonable thing to want. Curious about your use case, can you customize the header? Introducing an annotation for this should be straight-forward. Adding some sort of configuration seems a bit more tricky because we need a way to target fields and such which I don't think we have atm. |
I prefer not to customize the header. This is being generated from linux uapi headers. I don't need a way to target things though, I want this to apply universally. |
Ah, alright, then it should also be trivial. A patch that checks the context options here: rust-bindgen/src/codegen/mod.rs Line 3612 in c39c47c
Or even here: rust-bindgen/src/codegen/mod.rs Line 351 in c39c47c
Would do and should be straight-forward. |
These options allow specifying an alternate type to use where pointer types would otherwise be used. This is useful for binding to a WebAssembly guest, as well as for certain kinds of serialization and deserialization. Resolves rust-lang#2023.
These options allow specifying an alternate type to use where pointer types would otherwise be used. This is useful for binding to a WebAssembly guest, as well as for certain kinds of serialization and deserialization. Resolves rust-lang#2023.
These options allow specifying an alternate type to use where pointer types would otherwise be used. This is useful for binding to a WebAssembly guest, as well as for certain kinds of serialization and deserialization. Resolves rust-lang#2023.
I'd like to be able to customize the types of pointer types generated by bindgen. That is, the input:
would produce the output:
where
CustomPointer
is an arbitrary type path specified in configuration.The idea here is the custom pointer type can be a safe transparent wrapper around an integer value, which can e.g. treat the pointer as belonging to another process and read it from there.
The text was updated successfully, but these errors were encountered: