Velocity Reviews > Bitwise operation doesn't work

# Bitwise operation doesn't work

Andrew Usher
Guest
Posts: n/a

 12-16-2009
This line should set to 0 one bit of an array (of 32-bit values):

P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));

but it actually sets the whole word to zero. Since this is obviously
logically correct, can C not handle these things? I'm sure I have to
rewrite the whole god-damned thing in assembler.

Andrew Usher

Keith Thompson
Guest
Posts: n/a

 12-16-2009
Andrew Usher <(E-Mail Removed)> writes:
> This line should set to 0 one bit of an array (of 32-bit values):
>
> P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
> but it actually sets the whole word to zero. Since this is obviously
> logically correct, can C not handle these things?

[...]

It's not "obviously" logically correct without seeing the context.

Post a small complete program that exhibits the problem; tell us what
output you expected and what output you actually get.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Eric Sosman
Guest
Posts: n/a

 12-16-2009
On 12/15/2009 7:25 PM, Andrew Usher wrote:
> This line should set to 0 one bit of an array (of 32-bit values):
>
> P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
> but it actually sets the whole word to zero. Since this is obviously
> logically correct, can C not handle these things? I'm sure I have to
> rewrite the whole god-damned thing in assembler.

Perhaps you should review the the ! and the ~ operators,
and ponder why C has both, and speculate on what difference
there could possibly be between them.

Just a thought.

--
Eric Sosman
(E-Mail Removed)lid

bartc
Guest
Posts: n/a

 12-16-2009

"Andrew Usher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> This line should set to 0 one bit of an array (of 32-bit values):
>
> P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
> but it actually sets the whole word to zero. Since this is obviously
> logically correct, can C not handle these things? I'm sure I have to
> rewrite the whole god-damned thing in assembler.

Those double square brackets don't look right; perhaps there's a name
missing between those first two [[.

What's the value of the right-hand-side of the assignment at the point where
it doesn't work?

What's the value of the index to P?

If these values are A and B, then would you expect P[B] &= A to do what you
want? If not then you might need to change the code.

--
Bartc

Ben Bacarisse
Guest
Posts: n/a

 12-16-2009
Andrew Usher <(E-Mail Removed)> writes:

> This line should set to 0 one bit of an array (of 32-bit values):
>
> P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
> but it actually sets the whole word to zero. Since this is obviously
> logically correct, can C not handle these things?

There is a syntax error and lots of noise in that expression. If we
make the obvious correction to the synatx (P[[E]] should be P[E]) and
remove the noise, we get:

P[c>>5] &= !(1u << (c2 & 0x1f));

1u << by any number from 0 to 31 will be non-zero so ! of it will be
zero. ANDing with zero gives zero. You probably want ~ rather than !.

You really want 1u rather the 1 or 0x00000001 as the number to shift.
Also, you may want c in both places rather than c and c2.

<snip>
--
Ben.

Lew Pitcher
Guest
Posts: n/a

 12-16-2009
On December 15, 2009 19:25, in comp.lang.c, (E-Mail Removed) wrote:

> This line should set to 0 one bit of an array (of 32-bit values):
>
> P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
> but it actually sets the whole word to zero.

That's a complex statement you got there. Let's break it down into it's
parts

The RHS breaks down as

(c2 & 0x1f) results in an int between 0 and 31 (assuming c2 is an int)

0x01 << (c2 & 0x1f) results in one of 32 bits being set (assuming that
0x01 is a 32bit integer), making the result non-zero

!(0x01 << (c2 & 0x1f)) results in zero. ! changes zero values to 1 and
non-zero values to 0

So, on the RHS, we have 0 (or some sort of violation, for a non-int c2 or
ints that are smaller than 32bits wide)

The assignment operator is &=, which LOGICAL-ANDs the LHS with the RHS and
assigns the resulting value to the LHS.

Any integer LOGICAL-ANDed with 0 results in 0, so the LHS gets assigned 0

Let's look at that LHS:
P[[(c>>5)]]

Hmmmmm..... that's a notation that I'm unfamiliar with. Pedants and experts,
is that even a legal C construct?

I'm specifically referring to
P[[...]]
an anonymous subscript *within* a subscript?

> Since this is obviously logically correct,

Not so obviously. Certainly, it depends on some context, both with other
code (what sort of data items are <<c>> and <<c2>>?) and on the
capabilities of the compiler and environment you are working with (how big
is an int? what does the C compiler think of <<[[...]]>>?)

> can C not handle these things? I'm sure I have to
> rewrite the whole god-damned thing in assembler.

If you can, and you think that C won't handle the expression you are trying
to build, why don't you rewrite it in Assembler. Certainly, we have no
emotional investment in the languages you choose to write your code in.

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

FFreak
Junior Member
Join Date: Dec 2009
Posts: 1

 12-16-2009
test ........................

Doug Miller
Guest
Posts: n/a

 12-16-2009
In article <(E-Mail Removed)>, Andrew Usher <(E-Mail Removed)> wrote:
>This line should set to 0 one bit of an array (of 32-bit values):
>
>P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
>but it actually sets the whole word to zero. Since this is obviously
>logically correct, can C not handle these things?

In fact, it is obviously logically INcorrect. C handles "these things" just
fine. It's doing exactly what you told it to.

Hint: ! doesn't do what you think it does.

Keith Thompson
Guest
Posts: n/a

 12-16-2009
(E-Mail Removed) (Doug Miller) writes:
> In article <(E-Mail Removed)>, Andrew Usher <(E-Mail Removed)> wrote:
>>This line should set to 0 one bit of an array (of 32-bit values):
>>
>>P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>>
>>but it actually sets the whole word to zero. Since this is obviously
>>logically correct, can C not handle these things?

>
> In fact, it is obviously logically INcorrect. C handles "these things" just
> fine. It's doing exactly what you told it to.
>
> Hint: ! doesn't do what you think it does.

It doesn't do anything; it's a syntax error.

I don't believe it's possible to have two consecutive "[" tokens in a
valid C program.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Peter Nilsson
Guest
Posts: n/a

 12-16-2009
Keith Thompson <(E-Mail Removed)> wrote:
> ...I don't believe it's possible to have two consecutive
> "[" tokens in a valid C program.

#include <stdio.h>

#define STR(x) #x

int main(void)
{
puts(STR([[));
return 0;
}

--
Peter