On Thu, 2022-02-10 at 14:35 -0800, Andrii Nakryiko wrote: > let's stick to consistent snake_case naming convention > > let's also call it what the comment calls it :) "normalize_ints" ? > Sure, naming is hard. > So I thought about this a bit, I see how there could be a difference > of %lld vs %ld and such, but I think normalize should mean normalize > all ints, without any exceptions for kernel aliases. Let's keep the > rule simple: everything but char and bool gets converted to its > corresponding standard integer alias. > > Worst case few users might need to adjust their printf specifier after > seeing a compiler warning. When I first tried to do this, there were a couple of ways in which it was problematic: 1. format specifiers are all over selftests 2. passing uint64_t* to things expecting u64* in the userspace code Ultimately, this felt like a good compromise between keeping existing code working and also avoiding the major pitfalls of non-sized types. Another question here is whether a minor release of libbpf should be allowed to break the build of applications using -Werror. We could potentially gate this behavior behind a runtime arg but that's not exactly a "pit of success" type of design. > this is a different use case, let's not normalize anything unconditionally My bad, meant to remove this before submitting.
