frederick-vs-ja wrote: > > For what it’s worth, it looks like this introduces a series of `-Wformat` > > warnings when building the Linux kernel for 32-bit targets, which `typedef > > size_t` as `unsigned int` in > > [`include/linux/types.h`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/types.h?h=v6.16-rc6#n61) > > and [`include/uapi/asm-generic/posix_types.h`] > > The PR adds a check requiring that the value formatted by the `zu` format > specifier must be of type `size_t` (e.g., `std::size_t`, `::size_t`, or > `__size_t`), and not just `unsigned` or `unsigned long` (e.g., `1l` or > `1ul`). Currently, Clang appears to lose the type sugar during usual > arithmetic conversions, leading to this pedantic diagnostic. I'll look into > it. Since I'm new to Clang, I'm not sure whether this PR should be reverted > or kept while waiting for another PR to fix the issue.
This introduced false positives for `-Wformat`. The UB in `fscanf`/`fprintf` function families is based on the C type system, where `size_t` is not distinguished from its aliased type. It's merely non-portable, but not UB, to directly use the aliased type of `size_t` with `zu`. IMO we should avoid changing the behavior of `-Wformat`. And if we want to encourage more portable code, perhaps there should be a new warning. https://github.com/llvm/llvm-project/pull/143653 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
