Velocity Reviews > bitwise ORing

# bitwise ORing

Bill Cunningham
Guest
Posts: n/a

 03-23-2012
What would a function prototype look like that takes one parameter but
several options can be OR'd together in that parameter? For example:

function(LEFT|RIGHT);

What would the parameter source code look like?

Bill

Lew Pitcher
Guest
Posts: n/a

 03-23-2012
On Thursday 22 March 2012 21:56, in comp.lang.c, http://www.velocityreviews.com/forums/(E-Mail Removed)d wrote:

> What would a function prototype look like that takes one parameter but
> several options can be OR'd together in that parameter? For example:
>
> function(LEFT|RIGHT);
>
> What would the parameter source code look like?

Well, Bill, that depends....

What sort of argument does function() take?

If you are writing function(), then you should know what sort of input you
want it to take. OTOH, if function() has already been written, you can just
look at it to determine the argument type.

Given the little information that you've provided, we can eliminate some
values. Because you already know that the argument will be the result of
several values "Inclusively OR"ed together, you know that the argument must
be an integer type (1999-9899 6.5.12 "Bitwise Inclusive OR operator" - each
operand must be of integer type, and the usual arethmetic conversions will
be performed).

This means that the argument can't be a floatingpoint value (float, long
float, double, long double, long long float), a pointer, a structure or a
union. And that leaves char, unsigned char, short int, unsigned short int,
int, unsigned int, long int, unsigned long int, long long int or unsigned
long long int.

Now, tell us, which one of those is it?
--
Lew Pitcher

James Kuyper
Guest
Posts: n/a

 03-23-2012
On 03/23/2012 11:19 AM, Lew Pitcher wrote:
> On Thursday 22 March 2012 21:56, in comp.lang.c, (E-Mail Removed)d wrote:
>
>> What would a function prototype look like that takes one parameter but
>> several options can be OR'd together in that parameter? For example:
>>
>> function(LEFT|RIGHT);
>>
>> What would the parameter source code look like?

>
> Well, Bill, that depends....
>
> What sort of argument does function() take?
>
> If you are writing function(), then you should know what sort of input you
> want it to take. OTOH, if function() has already been written, you can just
> look at it to determine the argument type.
>
> Given the little information that you've provided, we can eliminate some
> values. Because you already know that the argument will be the result of
> several values "Inclusively OR"ed together, you know that the argument must
> be an integer type (1999-9899 6.5.12 "Bitwise Inclusive OR operator" - each
> operand must be of integer type, and the usual arethmetic conversions will
> be performed).
>
> This means that the argument can't be a floatingpoint value (float, long
> float, double, long double, long long float), a pointer, a structure or a
> union. And that leaves char, unsigned char, short int, unsigned short int,
> int, unsigned int, long int, unsigned long int, long long int or unsigned
> long long int.

Not quite - because of the integer promotions, the argument cannot be
any type with an integer conversion rank lower than int.

While what you've said is otherwise quite true for the argument of this
function, the corresponding parameter type could be any type that the
argument type can be implicitly converted to - which might be any
arithmetic type, even _Bool.

Joe keane
Guest
Posts: n/a

 03-23-2012
In article <4f6bca1d\$0\$32222\$(E-Mail Removed)>,
Bill Cunningham <(E-Mail Removed)> wrote:
>What would the parameter source code look like?

int function(struct foo *da_main_object, int some_other_important_value,
unsigned int opts)
{
...
}

Don Y
Guest
Posts: n/a

 03-23-2012
Hi Bill,

On 3/22/2012 6:56 PM, Bill Cunningham wrote:
> What would a function prototype look like that takes one parameter but
> several options can be OR'd together in that parameter? For example:
>
> function(LEFT|RIGHT);
>
> What would the parameter source code look like?

Usually, this is an integer (of some size) data type.
The manifest constants LEFT and RIGHT are typically disjoint
bitsets (though they need not be). They can also be derived
from an enumerated type, etc.

E.g., render_text(const char *string, attr_t attributes)

where:
attributes ::= BLINK | BOLD | DIM | INVISIBLE | ITALIC | etc.

(note my use of '|' here is in the context of a BNF, not a
C statement; also, this specfication says nothing about how
"sensible" BLINK | INVISIBLE might be! :> )

So,
render_text("Big SALE today!!", BOLD | BLINK);
one of the semantic problems with the use of "or" is that it
really is implementing what you would COLLOQUIALLY think of
as an "and" function: "Make this BOLD *and* BLINKing".

Unfortunately, using '+' as a more intuitive conjunctive
opens the door for all sorts of "hidden" errors. E.g.,
bit patterns can cause other unexpected results. For example,
BLINK + INVISIBLE == ITALIC (because the developer assumed
"BLINK + INVISIBLE" was meaningless -- "/* CAN'T HAPPEN */ -- and
chose the ITALIC bit pattern to coincide with this value,
by chance.

Of course, there are other perils with building values out
of bit masks but that's another story...

Bill Cunningham
Guest
Posts: n/a

 03-23-2012
Lew Pitcher wrote:
> Well, Bill, that depends....
>
> What sort of argument does function() take?
>
> If you are writing function(), then you should know what sort of
> input you want it to take. OTOH, if function() has already been
> written, you can just look at it to determine the argument type.
>
> Given the little information that you've provided, we can eliminate
> some values. Because you already know that the argument will be the
> result of several values "Inclusively OR"ed together, you know that
> the argument must be an integer type (1999-9899 6.5.12 "Bitwise
> Inclusive OR operator" - each operand must be of integer type, and
> the usual arethmetic conversions will be performed).
>
> This means that the argument can't be a floatingpoint value (float,
> long float, double, long double, long long float), a pointer, a
> structure or a union. And that leaves char, unsigned char, short int,
> unsigned short int, int, unsigned int, long int, unsigned long int,
> long long int or unsigned long long int.
>
> Now, tell us, which one of those is it?

I should've given an example of the function I've noticed takes this.
Right off my head I can't remember it exactly but it has to do with unix
socket programming. Some of the functions there take several OR'd together
responses.

Bill

Joachim Schmitz
Guest
Posts: n/a

 03-24-2012
Don Y wrote:
> Hi Bill,
>
> On 3/22/2012 6:56 PM, Bill Cunningham wrote:
>> What would a function prototype look like that takes one
>> parameter but several options can be OR'd together in that
>> parameter? For example:
>>
>> function(LEFT|RIGHT);
>>
>> What would the parameter source code look like?

>
> Usually, this is an integer (of some size) data type.
> The manifest constants LEFT and RIGHT are typically disjoint
> bitsets (though they need not be). They can also be derived
> from an enumerated type, etc.
>
> E.g., render_text(const char *string, attr_t attributes)
>
> where:
> attributes ::= BLINK | BOLD | DIM | INVISIBLE | ITALIC | etc.
>
> (note my use of '|' here is in the context of a BNF, not a
> C statement; also, this specfication says nothing about how
> "sensible" BLINK | INVISIBLE might be! :> )
>
> So,
> render_text("Big SALE today!!", BOLD | BLINK);
> one of the semantic problems with the use of "or" is that it
> really is implementing what you would COLLOQUIALLY think of
> as an "and" function: "Make this BOLD *and* BLINKing".

#define and | /* */
....
render_text("Big SALE today!!", BOLD and BLINK);

Bye, Jojo

Geoff
Guest
Posts: n/a

 03-25-2012
On Sat, 24 Mar 2012 11:29:16 +0100, "Joachim Schmitz"
<(E-Mail Removed)> wrote:

>#define and | /* */
>...
>render_text("Big SALE today!!", BOLD and BLINK);

Ouch, ouch, ouch! But cool.

Bill Cunningham
Guest
Posts: n/a

 03-25-2012
Lew Pitcher wrote:

> Well, Bill, that depends....
>
> What sort of argument does function() take?
>
> If you are writing function(), then you should know what sort of
> input you want it to take. OTOH, if function() has already been
> written, you can just look at it to determine the argument type.
>
> Given the little information that you've provided, we can eliminate
> some values. Because you already know that the argument will be the
> result of several values "Inclusively OR"ed together, you know that
> the argument must be an integer type (1999-9899 6.5.12 "Bitwise
> Inclusive OR operator" - each operand must be of integer type, and
> the usual arethmetic conversions will be performed).
>
> This means that the argument can't be a floatingpoint value (float,
> long float, double, long double, long long float), a pointer, a
> structure or a union. And that leaves char, unsigned char, short int,
> unsigned short int, int, unsigned int, long int, unsigned long int,
> long long int or unsigned long long int.
>
> Now, tell us, which one of those is it?

msgget with it's second parameter takes ORing. It just returns an int.
As to whether or not structs or unions are involved I don't know. man 2
msgget.

Bill

Lew Pitcher
Guest
Posts: n/a

 03-25-2012
On Sunday 25 March 2012 14:02, in comp.lang.c, (E-Mail Removed)d wrote:

> Lew Pitcher wrote:
>
>> Well, Bill, that depends....
>>
>> What sort of argument does function() take?

[snip]
>> Now, tell us, which one of those is it?

>
> msgget with it's second parameter takes ORing. It just returns an int.
> As to whether or not structs or unions are involved I don't know. man 2
> msgget.

OK, Bill

>>> What would a function prototype look like that takes one parameter but
>>> several options can be OR'd together in that parameter?

And now you say that you have the documentation for the function in
question. That documentation clearly provides the function prototype

: NAME
: msgget - get a message queue identifier
:
: SYNOPSIS
: #include <sys/types.h>
: #include <sys/ipc.h>
: #include <sys/msg.h>
:
: int msgget(key_t key, int msgflg);
/
See? That is the function prototype.

OK?
--
Lew Pitcher