I'm someone who really doesn't like it. The U in 1U << 31 is
unnecessary visual clutter that really makes the number harder to read
(I guess 1u is slightly better but not by that much). I think we
should define our code style first and foremost to make code easily
written and easily read (with no
Hi list,
Since register fields usually have more than one bit, I prefer to
always use explicit shifts for consistency. The one case where I
prefer the BIT() macro is to reduce the amount of nested braces when
testing for individual bits in a mask. GCC encourages adding
unnecessary braces for
Hi,
Although, I agree that 1u << 31 is much better, I believe 1 << 31 is not
wrong either as long as it is assigned to an 'unsigned int' as the compiler
performs an implicit conversion from a lower data type to a higher data
type ('int' to 'unsigned int' in this case). That's the reason the line
While I find the BIT() macro to be much better than the BITx defines
Why?
The BITx defines seem to be a rather redundant way of doing things to me.
I don't think it was invented by edk2, so edk2 using it shouldn't be
held against the format. :)
Sure, but that's where I remember seeing
Nico Huber wrote:
> So, it's wrong but not broken
..yet
> 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
Felix Held wrote:
> While I find the BIT() macro to be much better than the BITx defines
Why?
I don't think it was invented by edk2, so edk2 using it shouldn't be
held against the format. :)
> header files become a mix of BIT() and more than one bit shifted by x
> bits, which i find
Hi,
While I find the BIT() macro to be much better than the BITx defines in
edk2, I still prefer the non-macro form and at least in the subtrees I
maintain I try to get rid of BIT() usage in new code that gets merged.
Since BIT() can only be used for single bits and not for multiple bits
and
I will admit that I am a big fan of the `BIT` macro as well, but that seems
to not be as well-received, so if that's not an option, I would second `1u
<< 31`
On Thu, Jan 7, 2021 at 3:25 PM Furquan Shaikh
wrote:
> Would it make sense to use BIT(31)?
>
> On Thu, Jan 7, 2021 at 2:20 PM Matt
Would it make sense to use BIT(31)?
On Thu, Jan 7, 2021 at 2:20 PM Matt DeVillier wrote:
>
> `1u << 31` is correct, clear, and easy to read/understand quickly. It
> has my vote.
>
> On Thu, Jan 7, 2021 at 3:42 PM Nico Huber wrote:
> >
> > Hi coreboot fellows,
> >
> > another patch that fixes a
`1u << 31` is correct, clear, and easy to read/understand quickly. It
has my vote.
On Thu, Jan 7, 2021 at 3:42 PM Nico Huber wrote:
>
> Hi coreboot fellows,
>
> another patch that fixes a `1 << 31` to `1UL << 31` [1] reminded me that
> some people objected to such changes. I'm not sure if we
Hi coreboot fellows,
another patch that fixes a `1 << 31` to `1UL << 31` [1] reminded me that
some people objected to such changes. I'm not sure if we ever draw a
conclusion on the matter.
`1 << 31` is undefined behavior because the `1` can (and thus will) be
represented as a (signed) `int`
Hi,
I'm stuck at solving a problem on Intel platforms that might not be
one after all.
Tests showed that a HyperThreading enabled core must not update
microcodes on both threads at the same time, as the UCODE silicon is
shared between those threads and one update might fail. However, doing
so
12 matches
Mail list logo
