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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
