Bitwise Operators
Author Message
Bitwise Operators

Hi there,

I'm reading K&R2, and up to Bitwise Operators right now. It said that
bitwise AND operator & is often used to mask off some set of bits (And
that's what i've learnt from Assembly) .

It had an example like this:
n = n & 0177;

it said this'll sets to zero all but the low-order 7 bits of n.

What it means?

and it said :
x = x | SET_ON;
sets to one in x the bits that are set to one in SET_ON.

Does it means SET_ON has been declared as a variable or a symbolic constant
which is 1 in value?

Lastly, I want to ask. If a variable set to have a value of 0. Does it
equals to NULL? since NULL == 0.
--
Alexander L.
Fax no: 775-416-0149

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:
>Hi there,

>I'm reading K&R2, and up to Bitwise Operators right now. It said that
>bitwise AND operator & is often used to mask off some set of bits (And
>that's what i've learnt from Assembly) .

>It had an example like this:
>n = n & 0177;

>it said this'll sets to zero all but the low-order 7 bits of n.

>What it means?

0177 is the octal representation of 001 111 111

Let's have any number (say n = 0525 or 101 010 101 )

when you AND them, each bit is submitted to a logical AND
101 010 101
AND
001 111 111
gives
001 010 101

As you can see, the 0's of the 0177 mask have forced the original bits to 0,
and the 1's have left them at initial value.

Quote:
>and it said :
>x = x | SET_ON;
>sets to one in x the bits that are set to one in SET_ON.

>Does it means SET_ON has been declared as a variable or a symbolic constant
>which is 1 in value?

A sort of (some 1's) If I follow my previous example :

101 010 101
OR
001 111 111
gives
101 111 111

As you can see, the 1's of the 0177 mask have forced the original bits to 1,
and the 0's have left them at initial value.

Quote:

>Lastly, I want to ask. If a variable set to have a value of 0. Does it
>equals to NULL? since NULL == 0.

You can't say that. NULL is a macro supplied by *your* compiler. Its
definition is compiler-dependent.

Concerning the beginning of the sentence, it depences the type of the
variable.

char c=0;
int i=0;
long l=0;
float f=0;
void *p=0; (or NULL);

Is always correct, but concerning the f et p variables, the binary values
could be different from all bits to 0. The compiler knows what value is to
be encoded because of the type. This is the reason why :

int i=0;
void *p=i;

is a bug (types are different).

and I don't what to know what this could produce :

void *p=(void*)i;

--
-hs-
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:
> Hi there,

> I'm reading K&R2, and up to Bitwise Operators right now. It said that
> bitwise AND operator & is often used to mask off some set of bits (And
> that's what i've learnt from Assembly) .

> It had an example like this:
> n = n & 0177;

(...which is analogous to the general assignment form X = X OP Y, i.e.
perform the operation Y on X, storing the result in X... sorry if you

Quote:

> it said this'll sets to zero all but the low-order 7 bits of n.

0177 is an octal representation. In octal, each octit (!) represents three
bits. This is because it takes three bits to represent the number 7, which
is the highest octit commonly accepted to be valid. Since in 0177 we have
two 7s at the end, we can see that the lowest six bits are set, and the 1
makes the seventh. Here's a picture:

0   1   7   7 octal =

000 001 111 111 binary

Now for the AND operation, &. Single & is a bitwise operation (as opposed
to && which is a logical operation).

Here's the truth table for AND:

A   B   A & B
0   0     0
0   1     0
1   0     0
1   1     1

So A & B is only 1 if both A and B are 1. Now let's look at some random bit
pattern n:

n     0111010101010101110101
0177  0000000000000001111111

n & 0177  0000000000000001110101

Now let's consider what's happening here. Because the high-order bits of
0177 are all zero, all the corresponding bits in the result must be zero
too, because (in the AND truth table, any row which has zero in either of A
and B also has a zero in A & B.

So we need only look at the bottom 7 bits of n. Those which are set (i.e.
1) remain 1 in the result, and those which aren't, don't. Hence, the bits
in which we are not interested can be said to have been masked off, with

Quote:
> and it said :
> x = x | SET_ON;
> sets to one in x the bits that are set to one in SET_ON.

> Does it means SET_ON has been declared as a variable or a symbolic
constant
> which is 1 in value?

No. SET_ON is a mask again. This time it's for switching bits on, not off.

Let's assume this, just for the sake of argument:

#define SET_ON 0177

Now apply exactly the same method as before, except that we're using OR

A   B   A | B
0   0     0
0   1     1
1   0     1
1   1     1

Quote:

> Lastly, I want to ask. If a variable set to have a value of 0. Does it
> equals to NULL? since NULL == 0.

Think of NULL as 'the invalid pointer value'. It's a value you give to
pointers when you want them to be detectably invalid later.

From your source code's point of view, if you use 0 when you mean NULL,
it'll be converted for you. If you use NULL when you mean 0, you might get
a warning, and it's considered bad practice anyway.

If you are using pointers, use NULL.

If you are using anything else, use 0.

--
Richard Heathfield

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.

comp.lang.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

...

Quote:
> >Lastly, I want to ask. If a variable set to have a value of 0. Does it
> >equals to NULL? since NULL == 0.

> You can't say that. NULL is a macro supplied by *your* compiler. Its
> definition is compiler-dependent.

Are you sure about that? I don't have the standard at hand, only K&R2. From
there, NULL is defined in in <stdio.h> as "the null pointer". When used as a
pointer type, 0 is
also "the null pointer". Isn't it therefore valid to conclude NULL == 0? Of
course, this is independent
of the fact whether the null pointer is represented internally by an "all
zero's bit pattern" or not by

Maybe I'm missing the finer points here?

Duco

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:

> I'm reading K&R2, and up to Bitwise Operators right now. It said that
> bitwise AND operator & is often used to mask off some set of bits (And
> that's what i've learnt from Assembly) .

> It had an example like this:
> n = n & 0177;

> it said this'll sets to zero all but the low-order 7 bits of n.

> What it means?

0177 is an octal constant (because of the leading 0), which is equal to
127, and to (binary) 1111111. When you ask for n & 0177, the result is
that value which has all bits set that are set in n _and_ in 0177.
Example: suppose n is 131, which is (binary) 10000011. Then:
n      == 01111111 == 0177 == 127
0177   == 10000011 == 0203 == 131
n&0177 == 00000011 ==   03 ==   3

Quote:
> and it said :
> x = x | SET_ON;
> sets to one in x the bits that are set to one in SET_ON.

> Does it means SET_ON has been declared as a variable or a symbolic constant
> which is 1 in value?

Not necessarily; SET_ON has been declared to have all bits on which you
want to have set in the result. E.g.: you have a flag, called x. You
want to set bits 0 and 2 of this flag, and leave the rest unchanged.
SET_ON should then have bits 0 and 2 set, the rest reset: SET_ON == 5.
x        == 10010010
SET_ON   == 00000101
x|SET_ON == 10010111

Quote:
> Lastly, I want to ask. If a variable set to have a value of 0. Does it
> equals to NULL? since NULL == 0.

No; NULL may have been defined as (void *)0. Use NULL only in pointer
context, never to do arithmetic with. IOW, don't do this:

int i=NULL;

and don't do this, either:

int i=0;
int *ipointer=i; /* expecting this to do the same as int *ipointer=0; */

Use 0 for all non-pointer values; for pointers, you may use 0, or you
may use NULL; these are equivalent _only for pointers_.
You may find the FAQ list useful, especially section 5:
<http://www.eskimo.com/~scs/C-faq/top.html>.

Richard

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:
> Let's assume this, just for the sake of argument:

> #define SET_ON 0177

ASSUMPTIONS are not allowed onto the AGENDA.  Only ANALYSIS based in DATA.
Karl M, chair.

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:

> > Let's assume this, just for the sake of argument:

> > #define SET_ON 0177

> ASSUMPTIONS are not allowed onto the AGENDA.  Only ANALYSIS based in
DATA.
> Karl M, chair.

Karl, be resonable. One must always know under what assumptions the

/A

--
+---------------------+
| Andreas K?h?ri
| Uppsala University
| Sweden

Sent via Deja.com http://www.deja.com/

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:
>> >Lastly, I want to ask. If a variable set to have a value of 0. Does it
>> >equals to NULL? since NULL == 0.
>> You can't say that. NULL is a macro supplied by *your* compiler. Its
>> definition is compiler-dependent.
>Are you sure about that? I don't have the standard at hand, only K&R2. From
>there, NULL is defined in in <stdio.h> as "the null pointer". When used as
a
>pointer type, 0 is
>also "the null pointer". Isn't it therefore valid to conclude NULL == 0? Of
>course, this is independent
>of the fact whether the null pointer is represented internally by an "all
>zero's bit pattern" or not by

>Maybe I'm missing the finer points here?

Some defintions for NULL are
#define NULL ((void*)0)

Can you say that NULL *is* 0 ?

NULL is NULL, 0 is 0.

char *p=NULL;
has the same effect that
char *p=0;

But it does not mean that 0 equals NULL

--
-hs-
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:

> >> >Lastly, I want to ask. If a variable set to have a value of 0.
Does it
> >> >equals to NULL? since NULL == 0.
> >> You can't say that. NULL is a macro supplied by *your* compiler.
Its
> >> definition is compiler-dependent.

> >Are you sure about that? I don't have the standard at hand, only
K&R2. From
> >there, NULL is defined in in <stdio.h> as "the null pointer". When
used as
> a
> >pointer type, 0 is
> >also "the null pointer". Isn't it therefore valid to conclude NULL
== 0? Of
> >course, this is independent
> >of the fact whether the null pointer is represented internally by
an "all
> >zero's bit pattern" or not by

> >Maybe I'm missing the finer points here?

> Some defintions for NULL are
> #define NULL ((void*)0)

> Can you say that NULL *is* 0 ?

> NULL is NULL, 0 is 0.

> char *p=NULL;
> has the same effect that
> char *p=0;

> But it does not mean that 0 equals NULL

But 0==NULL does have to be true, because any two null pointers
are equal and both are null pointer constants.  If you had
int i=0; then i==NULL might be legal and true (if NULL is
a constant 0 with type int) or a constraint violation (if
NULL is ((void *)0) or an equivalent).

--
MJSR

Sent via Deja.com http://www.deja.com/

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:

> >> >Lastly, I want to ask. If a variable set to have a value of 0. Does it
> >> >equals to NULL? since NULL == 0.
> >> You can't say that. NULL is a macro supplied by *your* compiler. Its
> >> definition is compiler-dependent.

> >Are you sure about that? I don't have the standard at hand, only K&R2.
From
> >there, NULL is defined in in <stdio.h> as "the null pointer". When used
as
> a
> >pointer type, 0 is
> >also "the null pointer". Isn't it therefore valid to conclude NULL == 0?
Of
> >course, this is independent
> >of the fact whether the null pointer is represented internally by an "all
> >zero's bit pattern" or not by

> >Maybe I'm missing the finer points here?

> Some defintions for NULL are
> #define NULL ((void*)0)

> Can you say that NULL *is* 0 ?

> NULL is NULL, 0 is 0.

You present an example of vulgar-materialism here, or a truism as modern
COLLEGIATES seem to prefer.  Karl M, chair.

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators

Quote:

> > > Let's assume this, just for the sake of argument:

> > > #define SET_ON 0177

> > ASSUMPTIONS are not allowed onto the AGENDA.  Only ANALYSIS based in
> DATA.
> > Karl M, chair.

> Karl, be resonable. One must always know under what assumptions the
> analysis is to be made.

No, this was previously ruled-out for you.  A materialist EVALUATES objects
by ENUMERATING subjects.  The switch-over occurs when moving from LINEAR to
DIGITAL.  Any Questions?  Karl M, chair.

Sun, 25 Aug 2002 03:00:00 GMT
Bitwise Operators
I'm quite confuse with your point hs. If:
int i;
i = 0 is equal to i = NULL
(I mean set i to 0).

Why there's a difference between them?

Quote:

>>> >Lastly, I want to ask. If a variable set to have a value of 0. Does it
>>> >equals to NULL? since NULL == 0.
>>> You can't say that. NULL is a macro supplied by *your* compiler. Its
>>> definition is compiler-dependent.

>>Are you sure about that? I don't have the standard at hand, only K&R2.
From
>>there, NULL is defined in in <stdio.h> as "the null pointer". When used as
>a
>>pointer type, 0 is
>>also "the null pointer". Isn't it therefore valid to conclude NULL == 0?
Of
>>course, this is independent
>>of the fact whether the null pointer is represented internally by an "all
>>zero's bit pattern" or not by

>>Maybe I'm missing the finer points here?

>Some defintions for NULL are
>#define NULL ((void*)0)

>Can you say that NULL *is* 0 ?

>NULL is NULL, 0 is 0.

>char *p=NULL;
>has the same effect that
>char *p=0;

>But it does not mean that 0 equals NULL

>--
>-hs-
>CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>ISO-C Library: http://www.dinkum.com/htm_cl
>"It's specified. But anyone who writes code like that should be
>transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC

Mon, 26 Aug 2002 03:00:00 GMT

 Page 1 of 3 [ 31 post ] Go to page: [1] [2] [3]

Relevant Pages