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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
