AaronBallman wrote: > > I don't think we can do that, at least for C, because that means this code > > would then be accepted when it shouldn't be, right? > > Yeah, I am not sure we can do this now then. It seems odd to allow calls to > builtins to change their return 'type' (or at least, return sugar) based on > when they are included. Even if we did, we would have to make sure it > actually WAS SIZE_TYPE and not a different typedef. > > So I guess we're back to: are we ok with this? > > ``` > sizeof(int); // returns an unsigned integer type > #include <stddef.h> > sizeof(int); // now returns a typedef to an unsigned integer type > ```
That's why I was thinking the better approach is for both to return `__SIZE_TYPE__` but instead of `__SIZE_TYPE__` being explicitly `unsigned int` (or similar), it is a new type named `__size_t` which is compatible with what `__SIZE_TYPE__` used to expand to for each target. Then diagnostics, clangd, other tooling, etc has a way to differentiate the size (and ptrdiff) type from the underlying type when there are no typedefs present. 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
