Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #18947 > unrolled thread

bitwise ORing

Back to article view | Back to comp.lang.c

Contents

  bitwise ORing "Bill Cunningham" <nospam@nspam.invalid> - 2012-03-22 20:56 -0500
    Re: bitwise ORing pete <pfiland@mindspring.com> - 2012-03-22 21:29 -0500
    Re: bitwise ORing Lew Pitcher <lpitcher@teksavvy.com> - 2012-03-23 11:19 -0400
      Re: bitwise ORing James Kuyper <jameskuyper@verizon.net> - 2012-03-23 11:43 -0400
      Re: bitwise ORing "Bill Cunningham" <nospam@nspam.invalid> - 2012-03-23 16:23 -0500
      Re: bitwise ORing "Bill Cunningham" <nospam@nspam.invalid> - 2012-03-25 13:02 -0500
        Re: bitwise ORing Lew Pitcher <lpitcher@teksavvy.com> - 2012-03-25 16:26 -0400
    Re: bitwise ORing jgk@panix.com (Joe keane) - 2012-03-23 20:31 +0000
    Re: bitwise ORing Don Y <this@isnotme.com> - 2012-03-23 13:41 -0700
      Re: bitwise ORing "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2012-03-24 11:29 +0100
        Re: bitwise ORing Geoff <geoff@invalid.invalid> - 2012-03-24 19:06 -0700

#18947 — bitwise ORing

    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

[toc] | [next] | [standalone]

#18949

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?

/* BEGIN new.c */

#include <stdio.h>

#define LEFT        0xdead0000
#define RIGHT       0x0000beef

void
function(long unsigned X)
{
    printf("\n%lx\n", X);
}

int
main(void)
{
    function(LEFT|RIGHT);
    return 0;
}

/* END new.c */


-- 
pete

[toc] | [prev] | [next] | [standalone]

#18953

On Thursday 22 March 2012 21:56, in comp.lang.c, nospam@nspam.invalid 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

[toc] | [prev] | [next] | [standalone]

#18955

On 03/23/2012 11:19 AM, Lew Pitcher wrote:
> On Thursday 22 March 2012 21:56, in comp.lang.c, nospam@nspam.invalid 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.

[toc] | [prev] | [next] | [standalone]

#18968

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

[toc] | [prev] | [next] | [standalone]

#19029

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

[toc] | [prev] | [next] | [standalone]

#19034

On Sunday 25 March 2012 14:02, in comp.lang.c, nospam@nspam.invalid 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

I think that you answered your own question, then.

You originally asked
>>> 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

[toc] | [prev] | [next] | [standalone]

#18969

In article <4f6bca1d$0$32222$bbae4d71@news.suddenlink.net>,
Bill Cunningham <nospam@nspam.invalid> wrote:
>What would the parameter source code look like?

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

[toc] | [prev] | [next] | [standalone]

#18970

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.,
BLINK + BLINK might == BOLD, by coincidence.  Or, overlapping
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...

[toc] | [prev] | [next] | [standalone]

#18994

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

[toc] | [prev] | [next] | [standalone]

#19019

On Sat, 24 Mar 2012 11:29:16 +0100, "Joachim Schmitz"
<nospam.jojo@schmitz-digital.de> wrote:

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

Ouch, ouch, ouch! But cool.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web