================
@@ -226,7 +226,7 @@ class Preprocessor {
LangOptions::FPEvalMethodKind::FEM_UnsetOnCommandLine;
// Next __COUNTER__ value, starts at 0.
- unsigned CounterValue = 0;
+ unsigned long CounterValue = 0;
----------------
Sirraide wrote:
> I went with `unsigned long` because the standard requires the value to fit
> within a `signed long` explicitly; so it was for parity with the standards
> wording. WDYT?
Looking at what the paper specifies, I think it’s weird no matter which one you
choose because the standard both specifies that it should fit in a `signed
long` and that the maximum value is `2147483647`, but `2147483647` is *not* the
same as `LONG_MAX` e.g. on linux.
Also, ‘fits in a `signed long`’ is relative to whatever a `signed long` happens
to be on the target, whereas using `unsigned long` in Clang itself is relative
to whatever platform the compiler is running on, so there isn’t really any
correlation between the two (other than that both must be >= 32 bits as
specified by the standard).
I personally find `uint32_t` easier to read because it’s based on the maximum
value of `2147483647`, whereas `unsigned long` just ‘happens to work’ and
doesn’t really communicate intent—that said this might also just be my dislike
for implicit-width integer types showing (I try to avoid using `long` and
friends whenever possible).
https://github.com/llvm/llvm-project/pull/162662
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
