From: Ezekiel Newren Date: Mon, 22 Sep 2025 17:23:39 GMT Subject: Re: [PATCH v2 00/18] Introduce rust: In xdiff Message-ID: In-Reply-To: On Mon, Sep 22, 2025 at 10:47 AM Junio C Hamano wrote: > Ezekiel Newren writes: > > >> > I wanted feedback on: > >> > * Cleaning up Rust type name collisions > >> > * People don't like it, so I'll drop that > >> > >> I don't have a strong opinion on this. If it creates issues I personally > >> don't mind fixing it. > > > > Junio doesn't like it, so I'm not going to do it. > > It was not "I do not like u16 as a typename when a perfectly well > established uint16_t is available", though. > > It was more about asking to explain the reason behind insisting to > use u(8|16|32|64) types in C code. Perhaps there is a compelling > reason to do so that I was missing. I listed 5 reasons in my commit message[1], and I just thought of another one now. * Pseudo reserved keywords: 'new' is not a reserved keyword in C, but Git treats it as such. Since Rust will likely be added to Git, the Rust primitive types should also be treated as reserved keywords. Cbindgen parse's Rust and generates C header files; If a field in a struct uses u16 as the name then Rust won't compile, and cbindgen can't create the C header file. Using [ui](8|16|32|64|size) as the type in C also spreads awareness that those are reserved keywords and should not be used as variable names. If these 6 reasons are not enough to explain why we should be using the Rust primitive type names in C, then please explain how it is insufficient. > I know that the kernel has used these types for a long time, but > that way predates their more recent flirt with Rust. If your answer > was "the kernel uses them", then I'd want that answer to cover a few > additional questions, like > > - Have they benefited from their use of u(8|16|32|64) when they > started working with Rust and if so how? I did not know this. [1] https://lore.kernel.org/git/2a7d5b05c18d4a96f1905b7043d47c62d367cd2a.1757274320.git.gitgitgadget@gmail.com/