On 24/02/2021 14:16, Mark Wielaard wrote:>>> -#define NO_RESIZING 0u
-#define ALLOCATING_MEMORY 1u
-#define MOVING_DATA 3u
-#define CLEANING 2u
+#define NO_RESIZING 0x0
+#define ALLOCATING_MEMORY 0x1
+#define MOVING_DATA 0x3
+#define CLEANING 0x2
Nope, same result. :(
Hmm
On 24/02/2021 14:16, Mark Wielaard wrote:> Hmmm. I am not sure why that
doesn't work. What if you make them
explicitly unsinged (adding u at the end). Or does it simply ignore
the values and just warn because it sees the macro name and not an
explicit number?
Another viable workaround is to jus
On 24/02/2021 14:46, Timm Bäder wrote:
On 24/02/2021 14:16, Mark Wielaard wrote:
Hmmm. I am not sure why that doesn't work. What if you make them
explicitly unsinged (adding u at the end). Or does it simply ignore
the values and just warn because it sees the macro name and not an
explicit number
On 24/02/2021 14:16, Mark Wielaard wrote:
Hmmm. I am not sure why that doesn't work. What if you make them
explicitly unsinged (adding u at the end). Or does it simply ignore
the values and just warn because it sees the macro name and not an
explicit number?
I think I don't really understand any
Hi Timm,
On Thu, Feb 18, 2021 at 08:41:01AM +0100, Timm Bäder wrote:
> On 17/02/2021 17:49, Mark Wielaard wrote:
> >
> > I think both the comment and the warning message are a little
> > misleading.
> >
> > The comment should really read "Change state from CLEANING to
> > NO_RESIZING". You are r
On 17/02/2021 17:49, Mark Wielaard wrote:
I think both the comment and the warning message are a little
misleading.
The comment should really read "Change state from CLEANING to
NO_RESIZING". You are right that NO_RESIZING is just zero, but still
removing it seems to make the code less clear.
Hi Érico,
On Wed, 2021-02-17 at 15:15 -0300, Érico Nogueira wrote:
> Em 17/02/2021 13:49, Mark Wielaard escreveu:
> > -#define NO_RESIZING 0u
> > -#define ALLOCATING_MEMORY 1u
> > -#define MOVING_DATA 3u
> > -#define CLEANING 2u
> > +#define NO_RESIZING 0x0
> > +#define ALLOCATING_MEMORY 0
Em 17/02/2021 13:49, Mark Wielaard escreveu:
On Wed, 2021-02-17 at 11:12 +0100, Timm Bäder via Elfutils-devel wrote:
Hi,
I'm mainly leaving this patch here to discuss what to do about it.
Clang complains because of -Wxor-used-as-pow. So of course one
possibility is to use -Wno-xor-used-as-po
On Wed, 2021-02-17 at 11:12 +0100, Timm Bäder via Elfutils-devel wrote:
> Hi,
>
> I'm mainly leaving this patch here to discuss what to do about it.
> Clang complains because of -Wxor-used-as-pow. So of course one
> possibility is to use -Wno-xor-used-as-pow. It also prints
> '0x2 ^ NO_RESIZING' a
From: Timm Bäder
Clang complains about this because it has -Wxor-used-as-pow:
../../lib/dynamicsizehash_concurrent.c:288:61: error: result of 'CLEANING ^
NO_RESIZING' is 2; did you mean '1 << NO_RESIZING' (1)?
[-Werror,-Wxor-used-as-pow]
atomic_fetch_xor_explicit(&htab->resizing_state, CLEAN
Hi,
I'm mainly leaving this patch here to discuss what to do about it.
Clang complains because of -Wxor-used-as-pow. So of course one
possibility is to use -Wno-xor-used-as-pow. It also prints
'0x2 ^ NO_RESIZING' as an alternative to silence the warning. Given the
comment just above the changed li
11 matches
Mail list logo
