bitwise NOT

[Jonathan Pittman]

As I understand it, the ~ is a bitwise NOT in C.  And, in reading the spec, I believe &^ is the Go equivalent.  With that in mind, how would I do the following in Go?

#define ASYNC_INTERNAL_FLAGS    (~((1U << ASYNCB_FIRST_KERNEL) - 1))

I can get as far as...

const (

        ASYNC_INTERNAL_FLAGS = (1 << ASYNCB_FIRST_KERNEL) - 1

)

but all of these cause gofmt to yell and go run produces compile errors.

const (

        ASYNC_INTERNAL_FLAGS = (&^((1 << ASYNCB_FIRST_KERNEL) - 1))

        ASYNC_INTERNAL_FLAGS = &^((1 << ASYNCB_FIRST_KERNEL) - 1)

        ASYNC_INTERNAL_FLAGS &^= ((1 << ASYNCB_FIRST_KERNEL) - 1)

)

What is the syntax I need for this?

[Paul Hankin]

^ is the unary bitwise complement operator. &^ is binary 'and not' operator.

Here, I think you want:

ASYNC_INTERNAL_FLAGS = ^uint32(1 << ASYNCB_FIRST_KERNEL - 1)

-- 

Paul

[Jan Mercl]

'&^' is a binary operator: http://golang.org/ref/spec#Arithmetic_operators
The unary bitwise complement is '^' (same part of the spec near the
end of that section).

-j

[Jonathan Pittman]

Ah.  Okay.  I read...

&^   bit clear (and not)    integers

to mean "and NOT" not "AND NOT."  Thanks!

[Job van der Zwan]

Maybe it would be more clear if those operators were written in all caps in the comments.

[Jan Mercl]

On Mon, Sep 10, 2012 at 10:40 AM, Job van der Zwan
<j.l.van...@gmail.com> wrote:
> Maybe it would be more clear if those operators were written in all caps in
> the comments.

I'm not sure. I'm now confused what are the supposed differences
between 'and not', 'and NOT' and 'AND NOT'?

-j

[Patrick Mylund Nielsen]

It would; or if "bitwise" was prepended.

On Mon, Sep 10, 2012 at 10:40 AM, Job van der Zwan <j.l.van...@gmail.com> wrote:

[Jonathan Pittman]

"and NOT" vs "AND NOT"

grammar vs. identifiers

Using all caps would distinguish these as logical/bitwise operators as opposed to components of English grammar in a phrase or sentence.

[Jan Mercl]

On Sep 10, 2012 7:23 PM, "Jonathan Pittman" <jonathan.m...@gmail.com> wrote:
>
> "and NOT" vs "AND NOT"
>
> grammar vs. identifiers
>
> Using all caps would distinguish these as logical/bitwise operators as opposed to components of English grammar in a phrase or sentence.

I honestly thank you for the explanation but I'm too dumb to get it. The(se) operators have the  same semantics in an English sentence as they have in a programming language, so I fail to understand what the difference is (modulo lexical grammar).

Not your fault, but mine for sure, sorry.

-j

[Dan Kortschak]

What I think he's trying to get at is the difference between:

1. AND NOT - an operation that does a&^b.
2. and NOT - an operation that does both a&^b, and ^a.

[Job van der Zwan]

On Tuesday, 11 September 2012 08:27:34 UTC+2, kortschak wrote:

What I think he's trying to get at is the difference between:

1. AND NOT - an operation that does a&^b.
2. and NOT - an operation that does both a&^b, and ^a.

Exactly.

And of course, normally one should immediately realise the latter would be the most unlikely of these two possible interpretations, but imagine you're hacking away at 4 AM, don't even notice that there's two ways to interpret it, and too tired to notice the weirdness of the latter.

[Jan Mercl]

On Tue, Sep 11, 2012 at 8:27 AM, Dan Kortschak
<dan.ko...@adelaide.edu.au> wrote:
> What I think he's trying to get at is the difference between:
>
> 1. AND NOT - an operation that does a&^b.
> 2. and NOT - an operation that does both a&^b, and ^a.

Thanks! The RHSs are finally something I can understand even though
that interpretation (2.b) never came to my mind before ;-)

Sorry to all for me taking few days to wake up.

On Tue, Sep 11, 2012 at 8:47 AM, Job van der Zwan
<j.l.van...@gmail.com> wrote:
> And of course, normally one should immediately realise the latter would be
> the most unlikely of these two possible interpretations, but imagine you're
> hacking away at 4 AM, don't even notice that there's two ways to interpret
> it, and too tired to notice the weirdness of the latter.

True story ;-)

-j

[Dan Kortschak]

It actually took me a few goes to get it, so I'm not surprised you were confused.

[Jonathan Pittman]

Yes.  Thank you, Dan, for clarifying that.