================
@@ -226,7 +226,7 @@ class Preprocessor {
LangOptions::FPEvalMethodKind::FEM_UnsetOnCommandLine;
// Next __COUNTER__ value, starts at 0.
- unsigned CounterValue = 0;
+ unsigned long CounterValue = 0;
----------------
AaronBallman 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).
Oh, good call about this!
> 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).
Okay, that convinces me, I'll make the change. Thanks!
https://github.com/llvm/llvm-project/pull/162662
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
