[clang] [clang-tools-extra] [libcxx] [lldb] [Clang] Make the SizeType, SignedSizeType and PtrdiffType be named sugar types instead of built-in types (PR #143653)

A. Jiang via cfe-commits cfe-commits at lists.llvm.org
Fri Jul 18 01:22:02 PDT 2025


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


More information about the cfe-commits mailing list