[PATCH] D99456: [C++2b] Support size_t literals

Anton Bikineev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 30 13:40:57 PDT 2021


AntonBikineev marked an inline comment as done.
AntonBikineev added inline comments.


================
Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:198-200
+def err_size_t_literal_too_large: Error<
+  "%select{signed |}0'size_t' literal is out of range of possible "
+  "%select{signed |}0'size_t' values">;
----------------
rsmith wrote:
> I wonder if it'd be better to say `'ssize_t'` instead of `signed 'size_t'` here? The latter sounds self-contradictory since `size_t` is an unsigned type.
I thought about it (and actually had it first as ssize_t). The problem with ssize_t is that it's not defined by C or C++ Standards, AFAIK, but by POSIX. The proposal calls it "the signed integer type corresponding to std::size_t", so I decided to shorten it to "signed 'size_t'". However, I don't have strong opinion on this.


================
Comment at: clang/lib/Sema/SemaExpr.cpp:3895
       // be an unsigned int.
       bool AllowUnsigned = Literal.isUnsigned || Literal.getRadix() != 10;
 
----------------
rsmith wrote:
> AntonBikineev wrote:
> > I now begin to think that we should probably also prohibit things like 0x1234z to be implicitly interpreted as unsigned. Wdyt?
> Table 8 says that a `z`-suffixed literal has type `ssize_t` (if the value fits) or `size_t` (otherwise), so I think taking `AllowUnsigned` into account is correct (although perhaps surprising).
Thanks for pointing this out! Changed it back and fixed the tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99456/new/

https://reviews.llvm.org/D99456



More information about the cfe-commits mailing list