how important are bitwise operators?

[Andy]

I'm currently learning C with K&R and I was going over the
section with the Bitwise operators.
What exactly are usefull uses for them?
Are they really important?
thanks in advance.

 

[Mark A. Odell]

I'm currently learning C with K&R and I was going over the
section with the Bitwise operators.
What exactly are usefull uses for them?

When you want to pack a bunch of statii into a single integer. When you
want to check alignment of a pointer.

e.g.

#define FLAG_1 (1 << 0)
#define FLAG_2 (1 << 1)
#define FLAG_3 (1 << 2)

unsigned int flags;

if (flags & (FLAG_1 | FLAG_3))
printf("Flag 1 and 3 are set\n");


char *ptr = malloc(1024);

if (ptr && !((unsigned int) ptr & 0xF))
printf("Got a pointer with alignment I can use\n");

Are they really important?

Very!

 

[osmium]

I'm currently learning C with K&R and I was going over the
section with the Bitwise operators.
What exactly are usefull uses for them?
Are they really important?

They are important but I wouldn't get stressed out over them if I were you.
If you can't appreciate them at the moment, let it pass, if you keep
programming their usage will become clear to you sooner or later.

One example: the exclusive or operator is almost essential for cryptographic
work.

 

[nobody]

When you want to pack a bunch of statii into a single integer. When you
want to check alignment of a pointer.

e.g.

#define FLAG_1 (1 << 0)
#define FLAG_2 (1 << 1)
#define FLAG_3 (1 << 2)

unsigned int flags;

if (flags & (FLAG_1 | FLAG_3))
printf("Flag 1 and 3 are set\n");


char *ptr = malloc(1024);

if (ptr && !((unsigned int) ptr & 0xF))
printf("Got a pointer with alignment I can use\n");

Out of curiosity, under what circumstances would conforming
implementation return non-null unsuitably aligned pointer
(for legal uses of such pointer)? Thanks.

 

[Arthur J. O'Dwyer]

Out of curiosity, under what circumstances would conforming
implementation return non-null unsuitably aligned pointer
(for legal uses of such pointer)? Thanks.

First of all, we should note that Mark's trying to
cast 'ptr' from 'char *' to 'unsigned int', which right
off the bat won't necessarily work the way anyone might
expect it to.
Then note that he's ANDing it with 0xF to "check"
its alignment, which only works if properly aligned
pointers on your system happen to be converted to
unsigned ints with the lower four bits cleared. That's
not a valid assumption on the platform I'm familiar
with.
Finally, to answer nobody's question, ;-) a conforming
implementation *cannot* return an "unsuitably aligned"
pointer from a conforming call to 'malloc' (i.e., a call
that doesn't invoke undefined behavior all by itself).
'malloc' always returns pointers suitably aligned for
any type, which means you never have to do the sort of
non-portable "checking" Mark described above.

<OT>
Maybe 'sbrk' or the equivalent on some systems
doesn't return nicely aligned chunks of memory, so
you'd have to test there. But that's off-topic
in comp.lang.c. Ask a systems group if you *really*
want to know. (Really OT: And if you've been keeping
track of my grammar, you'll know what this last sentence
is about.)
</OT>

-Arthur,
ungrammatical to the last

 

[Glen Herrmannsfeldt]

Finally, to answer nobody's question, ;-) a conforming
implementation *cannot* return an "unsuitably aligned"
pointer from a conforming call to 'malloc' (i.e., a call
that doesn't invoke undefined behavior all by itself).
'malloc' always returns pointers suitably aligned for
any type, which means you never have to do the sort of
non-portable "checking" Mark described above.

Depending on your definition of suitable. As I understand, for
implementations that can use unaligned pointers, but perform slower with
them, they are allowed. As the C standard makes no claims to the speed of
operations, that could be true.

If I am writing a program that needs to be fast, I would call the
suboptimally aligned pointer unsuitable.

-- glen

 

[nobody]

First of all, we should note that Mark's trying to
cast 'ptr' from 'char *' to 'unsigned int', which right
off the bat won't necessarily work the way anyone might
expect it to.
Then note that he's ANDing it with 0xF to "check"
its alignment, which only works if properly aligned
pointers on your system happen to be converted to
unsigned ints with the lower four bits cleared. That's
not a valid assumption on the platform I'm familiar
with.

Thanks for an answer.
Yes, I've noted it, just didn't want to comment on it.
/* Also, I personally would use e.g
#define FLAG_1 0x01
instead of
#define FLAG_1 (1 << 0) */

Finally, to answer nobody's question, ;-) a conforming
implementation *cannot* return an "unsuitably aligned"
pointer from a conforming call to 'malloc' (i.e., a call
that doesn't invoke undefined behavior all by itself).
'malloc' always returns pointers suitably aligned for
any type, which means you never have to do the sort of
non-portable "checking" Mark described above.

I just wanted to make sure that I didn't (yet again) mis-read
N869. Though even I agree with final answer (bitwise operators
are very important), it seems to me that given examples were
not the best choice for supporting this answer (not that I
have any better).

 

[nobody]

Depending on your definition of suitable.

Not really. I meant "suitable aligned" as meant by 7.20.3p1,
whatever that means (no, it's not a question).

As I understand, for
implementations that can use unaligned pointers, but perform slower with
them, they are allowed. As the C standard makes no claims to the speed of
operations, that could be true.

If I am writing a program that needs to be fast, I would call the
suboptimally aligned pointer unsuitable.

Well, difference of opinion. Considering topicality, I would
call it 'inconveniently' aligned. Can't imagine how one could
force malloc() to return pointer with specific alignment.

 

[Mark A. Odell]

Thanks for an answer.
Yes, I've noted it, just didn't want to comment on it.
/* Also, I personally would use e.g
#define FLAG_1 0x01
instead of
#define FLAG_1 (1 << 0) */

You know when you have a list of them, it becomes more clear my way (IMHO)
especially with the PowerPC and IBM's damn backwards bits. E.g. if you
want to create masks for an IBM PowerPC register using IBM's bit notation
from the data book without translating in your brain you just do this:

/* flag reg. IBM datasheet
** width size bit position
** - 1
** | | |
** v v v */
#define CPC0_CR0_TRE (1 << 31 - 4)
#define CPC0_CR0_G10E (1 << 31 - 5)
#define CPC0_CR0_G11E (1 << 31 - 6)
#define CPC0_CR0_G12E (1 << 31 - 7)
#define CPC0_CR0_G13E (1 << 31 - 8)
#define CPC0_CR0_G14E (1 << 31 - 9)
#define CPC0_CR0_G15E (1 << 31 - 10)
#define CPC0_CR0_G16E (1 << 31 - 11)
#define CPC0_CR0_G17E (1 << 31 - 12)
#define CPC0_CR0_G18E (1 << 31 - 13)
#define CPC0_CR0_G19E (1 << 31 - 14)
#define CPC0_CR0_G20E (1 << 31 - 15)
#define CPC0_CR0_G21E (1 << 31 - 16)
#define CPC0_CR0_G22E (1 << 31 - 17)
#define CPC0_CR0_G23E (1 << 31 - 18)
#define CPC0_CR0_DCS (1 << 31 - 19)
#define CPC0_CR0_RDS (1 << 31 - 20)
#define CPC0_CR0_DTE (1 << 31 - 21)
#define CPC0_CR0_DRE (1 << 31 - 22)
#define CPC0_CR0_DAEC (1 << 31 - 23)
#define CPC0_CR0_U0EC (1 << 31 - 24)
#define CPC0_CR0_U1EC (1 << 31 - 25)

Maybe you can quickly translate IBM's bit 4 into 0x0800'0000 but I cannot,
certainly not reliably.