Bitwise operation doesn't work
Andrew Usher
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
> 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) ks...@mib.org <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
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
eso...@ieee-dot-org.invalid
bartc
"Andrew Usher" <k_over...@yahoo.com> wrote in message
news:ed2142c7-b008-4a1e...@d9g2000prh.googlegroups.com...
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
> 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
> 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. ------
Doug Miller
>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
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.
Peter Nilsson
> ...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
Andrew Usher
OK, I'll reply to all of you.
First, I typed in this line by hand which accounts for the syntax
error and the c/c2 difference - I name all my random integer variables
c, c2, etc. and sometimes get them mixed up.
It was indeed the ! operator that was wrong. I'd never heard of the ~
operator before, but I figured it out from this thread. I never
learned C formally, and have never seen a list of all the features of
C, such as operators.
Andrew Usher
Keith Thompson
Where are the "[" tokens? All I see is a pair of "[" preprocessing
tokens.
(Good answer nonetheless.)
Ian Collins
Then you should buy a copy of K&R2 without delay!
--
Ian Collins
Nick Keighley
> Andrew Usher wrote:
<snip>
> > I never
> > learned C formally, and have never seen a list of all the features of
> > C, such as operators.
>
> Then you should buy a copy of K&R2 without delay!
or ask santa
Mark Bluemel
> It was indeed the ! operator that was wrong. I'd never heard of the ~
> operator before, but I figured it out from this thread. I never
> learned C formally, and have never seen a list of all the features of
> C, such as operators.
Should we introduce this guy to Bill?
Eric Sosman
> [...]
> It was indeed the ! operator that was wrong. I'd never heard of the ~
> operator before, but I figured it out from this thread. I never
> learned C formally, and have never seen a list of all the features of
> C, such as operators.
Ah, so your antagonistic tone in "Since this is obviously
logically correct, can C not handle these things?" was utterly
unwarranted?
Seriously: If you expect to get any value out of using a
tool, particularly an intricate tool like a programming language,
you had better plan on spending some time learning what the tool
does. If your hammer applies paint unevenly, don't blame the
hammer!
--
Eric Sosman
eso...@ieee-dot-org.invalid
Edward A. Falk
Andrew Usher <k_over...@yahoo.com> wrote:
>
>P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
OK, first, why did you make it so unreadable? Is this part of some
obfuscated programming contest?
P[[c>>5]] &= !(1 << (c2 & 0x1f));
That's a little better.
OK, now I see your problem. Learn the differences between ! and ~
--
-Ed Falk, fa...@despams.r.us.com
http://thespamdiaries.blogspot.com/
Richard Tobin
Mark Bluemel <mark.b...@googlemail.com> wrote:
>On 16 Dec, 05:07, Andrew Usher <k_over_hb...@yahoo.com> wrote:
>Should we introduce this guy to Bill?
You might want to take a look at some of his other usenet postings
before engaging with him.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Andrew Usher
>
> Then you should buy a copy of K&R2 without delay!
Perhaps I should look for it.
Andrew Usher
Andrew Usher
> On 12/16/2009 12:07 AM, Andrew Usher wrote:
> > [...]
> > It was indeed the ! operator that was wrong. I'd never heard of the ~
> > operator before, but I figured it out from this thread. I never
> > learned C formally, and have never seen a list of all the features of
> > C, such as operators.
>
> Ah, so your antagonistic tone in "Since this is obviously
> logically correct, can C not handle these things?" was utterly
> unwarranted?
Strictly, I wasn't wrong: it is _logically_ correct, in that it
expresses what I meant, it just isn't proper C. But I suppose it was
excessive.
Andrew Usher
Andrew Usher
> In article <ed2142c7-b008-4a1e...@d9g2000prh.googlegroups.com>,
> Andrew Usher <k_over...@yahoo.com> wrote:
> >This line should set to 0 one bit of an array (of 32-bit values):
> >
> >P[[(c>>5)]]&=(!((0x00000001)<<(c2&0x0000001f)));
>
> OK, first, why did you make it so unreadable? Is this part of some
> obfuscated programming contest?
>
> P[[c>>5]] &= !(1 << (c2 & 0x1f));
>
> That's a little better.
I've gotten used to that style of inserting all possible parentheses
because I never learned the precedence of logical operators. Even so,
some of them should probably be removed.
Andrew Usher
Joe Wright
It is invaluable. I bought it on Amazon for $40 some time ago. I also have
K&R1 (1978). I treasure both books.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."