Hi,
On 08.01.21 01:26, Peter Stuge wrote:
Nico Huber wrote:
So, it's wrong but not broken
..yet
that's right. But I think chances are incredibly low that C compilers would change this behavior. Of all the things that I'm worried about that could change, this case -- shifting out of the range of a signed integer but still in range of an unsigned -- seems the least worrisome.
What do you think? Should we allow such changes?
I think yes.
Should we normalize on any style?
There is an argument to be made for allowing many different styles, but I think it would be wise to standardize.
my personal preference would be `1u << 31`.
That looks nicer, but based purely on my limited experience with C source code seems a lot less common than UL. Are there any relevant compatibility matters known, for the different suffixes?
Not for the suffixes but the types they represent. I would like to avoid `long` at all costs. Simply because we have LP64 and LP32 targets. That means `long` is not a single type for our code, it could be a 32 or a 64-bit type.
I think that `UL` is commonly used is just because it covers most cases of tools complaining (it's not necessarily the right choice in every instance, though).
Now that I looked, BIT() is defined using `ul`. If I'm not mistaken, this means you can use something like BIT(32) and the code would even pass all tools for an LP64 target. But if you use the same code for a 32-bit target later...
A quick fix could be to use `ull`. But it doesn't fix the underlying problem: The macro is hiding the type used. Encoding the type into the macro name could fix that, e.g. BIT32(), BIT64(), but I guess that would make it less useful for readability.
Nico