«

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

Andrew Usher <> 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) kst- <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"

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
lid

"Andrew Usher" <> wrote in message
news:ed2142c7-b008-4a1e-a027-...
> 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

Andrew Usher <> 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.

On December 15, 2009 19:25, in comp.lang.c, 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]

test ........................

In article <ed2142c7-b008-4a1e-a027->, 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?

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.

(Doug Miller) writes:
> In article <ed2142c7-b008-4a1e-a027->, 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?
>
> 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) kst- <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"

Keith Thompson <ks...@mib.org> 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