[clang] [Clang] Make the result type of sizeof/pointer subtraction/size_t lit… (PR #136542)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 23 11:59:00 PDT 2025


AaronBallman wrote:

> Something being unspecified in the standard doesn't mean we're unconstrained. In this case, it is unspecified because it is allowed to vary between platforms, but platforms are required to specify what type `size_t` is, and it is well-defined to write code based on that assumption on that platform. Unportable code is not invalid code. Almost all C and C++ code makes some non-portable assumptions, and this one in particular is very common.
> 
> Moreover, C++ encodes the underlying type of typedefs into the ABI. `size_t` appears in a lot of type signatures, and it is mangled as its underlying type. (This is actually very annoying for writing portable compiler tests because e.g. `operator new(size_t)` has a different mangled name on different targets, but we just have to deal with it.) The type produced by `sizeof` expressions can similarly easily propagate into the ABI through template argument deduction and `auto`. None of this can be changed without massively breaking the ABI. It is off the table.
> 
> Now, C might be different because of how loose the compatible-types rule is. If you want to pursue this just for C, we can talk about it; I don't know that it's a good idea, but we can at least talk about it.

Okay, I see where the disconnect is now. I was using standards terms like "compatible" when what I was really meaning was "alias". e.g., I wasn't suggesting we introduce a distinct, new type. I was suggesting we take the existing types and give them a spelling of `__size_t`. Same for how we already handle things like `_int32` and `int`; they're the same type, just with different ways of spelling it.

But I'm more and more thinking Richard is correct, this is just a fancy form of sugar.

https://github.com/llvm/llvm-project/pull/136542


More information about the cfe-commits mailing list