Description
It would be great if the Rust code generated by bindgen would keep the number bases of the integer literals in the input C and C++ code. After all, the writer of the C or C++ code probably had a good reason for using a specific radix.
C++141, C232, and Rust3 all support binary, octal, and hexadecimal base numbers, with C++14 and C23 sharing the same syntax. A one-to-one mapping with Rust seems to be possible.
For example, given the following code working in both C23 and C++14:
#define BIN_LIT 0b10
#define OCT_LIT 010
#define HEX_LIT 0x10the generated Rust bindings would be:
pub const BIN_LIT: u32 = 0b10;
pub const OCT_LIT: u32 = 0o10;
pub const HEX_LIT: u32 = 0x10;The bases of consts and enums would be kept as well.
A bit of not too serious motivation
Just for the reference, if someone finds this interesting. I ran the following command in a fresh git clone of the Linux kernel repository, finding lines in .h files only that have a #define with a hexadecimal literal later on that line:
rg "\#define.+\b0x" --type h | wc -l
Currently, that's 4 519 652 such lines.
Footnotes
-
ISO/IEC 14882:2014 draft N3054, chapter 6.4.4.1 Integer constants ↩
-
ISO/IEC 9899:2023 draft N3797, chapter 2.14.2 Integer literals ↩
-
Rust Reference: 2.6 Tokens, Number literals, 8.2.1 Literal expressions, Integer literals expressions ↩
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Participants
Activity
miikkas commentedon Jun 18, 2025
I have actually made an attempt at a prototype for this, which I'll submit as a PR shortly.
[-]Keep the integer literal radices of C in generated Rust[/-][+]Keep the integer literal radices of C and C++ in generated Rust[/+]miikkas commentedon Jul 12, 2025
This feature would presumably be somewhat invasive: Many projects updating bindgen would possibly need to update lots of generated bindings with literal values changed to use the original radix. This, in turn, might lead to a lot of work in those projects to review and test changes, or cause them to postpone updating bindgen.
If that is a concern, to reduce churn and allow some breathing room for projects using bindgen, the introduction of the feature could be phased by adding an option to
Builderthat would default to disabling the feature in the first version where it is introduced, then moving on to defaulting to enabling it in the next version, then deprecating the option in the next, and so on. What do you think?