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

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

c99 and the lack of warnings when int operations are applied to a bool

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

Contents

  c99 and the lack of warnings when int operations are applied to a bool mathog <dmathog@gmail.com> - 2012-03-23 08:40 -0700
    Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-03-23 12:07 -0400
    Re: c99 and the lack of warnings when int operations are applied to a bool jacob navia <jacob@spamsink.net> - 2012-03-23 21:45 +0100
      Re: c99 and the lack of warnings when int operations are applied to a bool Robert Wessel <robertwessel2@yahoo.com> - 2012-03-23 17:17 -0500
        Re: c99 and the lack of warnings when int operations are applied to a bool jacob navia <jacob@spamsink.net> - 2012-03-23 23:29 +0100
          Re: c99 and the lack of warnings when int operations are applied   to a bool Ian Collins <ian-news@hotmail.com> - 2012-03-24 11:48 +1300
            Re: c99 and the lack of warnings when int operations are applied   to a bool jacob navia <jacob@spamsink.net> - 2012-03-24 23:47 +0100
              Re: c99 and the lack of warnings when int operations are applied   to a bool Willem <willem@toad.stack.nl> - 2012-03-25 09:05 +0000
                Re: c99 and the lack of warnings when int operations are applied   to a bool "BartC" <bc@freeuk.com> - 2012-03-25 11:30 +0100
                  Re: c99 and the lack of warnings when int operations are applied   to a bool Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-25 21:05 +0100
                    Re: c99 and the lack of warnings when int operations are applied   to a bool Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-25 16:15 -0400
                      Re: c99 and the lack of warnings when int operations are applied   to a bool Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-25 22:14 +0100
                        Re: c99 and the lack of warnings when int operations are applied   to a bool James Kuyper <jameskuyper@verizon.net> - 2012-03-25 23:46 -0400
                          Re: c99 and the lack of warnings when int operations are applied to a bool Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-26 12:05 +0100
                            Re: c99 and the lack of warnings when int operations are applied to a bool Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-26 15:22 -0400
                Re: c99 and the lack of warnings when int operations are applied to a bool Gareth Owen <gwowen@gmail.com> - 2012-03-25 11:44 +0100
                  Re: c99 and the lack of warnings when int operations are applied to a bool Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-25 13:06 +0100
              Re: c99 and the lack of warnings when int operations are applied to a bool Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-27 11:12 -0700
          Re: c99 and the lack of warnings when int operations are applied to a bool Robert Wessel <robertwessel2@yahoo.com> - 2012-03-24 01:15 -0500
            Re: c99 and the lack of warnings when int operations are applied to a bool jacob navia <jacob@spamsink.net> - 2012-03-24 23:29 +0100
      Re: c99 and the lack of warnings when int operations are applied to a bool mathog <dmathog@gmail.com> - 2012-03-27 09:53 -0700
        Re: c99 and the lack of warnings when int operations are applied to a bool Keith Thompson <kst-u@mib.org> - 2012-03-27 11:07 -0700
        Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-03-27 14:16 -0400
        Re: c99 and the lack of warnings when int operations are applied to a bool Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-26 07:57 -0400
          Re: c99 and the lack of warnings when int operations are applied to a bool jacob navia <jacob@spamsink.net> - 2012-04-26 14:08 +0200
          Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-04-26 09:09 -0400
            Re: c99 and the lack of warnings when int operations are applied to a bool Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-26 21:29 -0400
              Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-04-26 21:58 -0400
                Re: c99 and the lack of warnings when int operations are applied to a bool Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-26 22:32 -0400
                  Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-04-27 06:31 -0400
                  Re: c99 and the lack of warnings when int operations are applied to a bool ImpalerCore <jadill33@gmail.com> - 2012-04-27 08:31 -0700

Page 1 of 2  [1] 2  Next page →

#18954 — c99 and the lack of warnings when int operations are applied to a bool

I just found out the hard way that the C99 "bool" type can result in 
some very hard to diagnose bugs.  This problem came up in the context of 
a field in a structure which had been declared in a file "long ago and 
far away" and which I had not seen.  From the usage in the file where 
the problem was found it looked like this value was an int, but it was a 
bool.  As it turns out at least the gcc compiler (4.4.1) gives no 
warnings when bools are used in ways that are "int" like but make little 
or no sense for a bool.

Example code showing some of these issues:

/* testbool.c */
#include <stdlib.h>
#include <stdio.h>
#include <stdbool.h>

void main(void){
bool avar;
   avar=1;
   (void) fprintf(stdout,"avar = %d\n",avar);
   avar=2;
   (void) fprintf(stdout,"avar = %d\n",avar);
   avar+=2;
   (void) fprintf(stdout,"avar = %d\n",avar);
   avar &= 2;
   (void) fprintf(stdout,"avar = %d\n",avar);
   avar=2;
   if(avar==2){
     (void) fprintf(stdout,"avar == 2\n");
   }
   else {
     (void) fprintf(stdout,"avar != 2\n");
   }
}

# gcc -Wall -std=c99 -o testbool testbool.c
testbool.c:5: warning: return type of 'main' is not 'int'
# ./testbool
avar = 1
avar = 1
avar = 1
avar = 0
avar != 2

To my mind the only two of these statements that make sense as operators 
on a bool are "=1" and "=2", both setting the bool to 1 (true), and the 
second one only if

   bool_variable = int_variable;

is always automatically converted to

   bool_variable = (bool) int_variable;

The rest of them make little or no sense for an operation on a bool, yet 
the compiler gives not a hint of a problem.  For instance, there is no 
point, ever, in incrementing a bool by 2 since the most it can change is 
by 1.  Similarly logic on any but the lowest bit is pointless since they 
will never be set.  Finally, the test "avar == 2" really should trigger 
a warning since a bool can never be 2, and the 2 is not automatically 
promoted to a bool (maybe the bool is promoted to an int?)  In any case 
the test is clearly a programming error since it can never be true, and 
the compiler can know that without having to reference any other piece 
of code.  Seems to me that if this does not generate a warning then the 
compiler should be doing it the other way around, consider the "2" as a 
bool, thus true, and the result should be True.  (Which it isn't.)

What exactly are the rules for bool such that the behavior shown above 
all makes sense (and is not worthy of a compiler warning)?

Thanks,

David Mathog

[toc] | [next] | [standalone]

#18956

On 03/23/2012 11:40 AM, mathog wrote:
> I just found out the hard way that the C99 "bool" type can result in 
> some very hard to diagnose bugs.  This problem came up in the context of 
> a field in a structure which had been declared in a file "long ago and 
> far away" and which I had not seen.  From the usage in the file where 
> the problem was found it looked like this value was an int, but it was a 
> bool.  As it turns out at least the gcc compiler (4.4.1) gives no 
> warnings when bools are used in ways that are "int" like but make little 
> or no sense for a bool.
> 
> Example code showing some of these issues:
> 
> /* testbool.c */
> #include <stdlib.h>
> #include <stdio.h>
> #include <stdbool.h>
> 
> void main(void){
> bool avar;
>    avar=1;
>    (void) fprintf(stdout,"avar = %d\n",avar);
>    avar=2;
>    (void) fprintf(stdout,"avar = %d\n",avar);
>    avar+=2;
>    (void) fprintf(stdout,"avar = %d\n",avar);
>    avar &= 2;
>    (void) fprintf(stdout,"avar = %d\n",avar);
>    avar=2;
>    if(avar==2){
>      (void) fprintf(stdout,"avar == 2\n");
>    }
>    else {
>      (void) fprintf(stdout,"avar != 2\n");
>    }
> }
> 
> # gcc -Wall -std=c99 -o testbool testbool.c
> testbool.c:5: warning: return type of 'main' is not 'int'
> # ./testbool
> avar = 1
> avar = 1
> avar = 1
> avar = 0
> avar != 2
> 
> To my mind the only two of these statements that make sense as operators 
> on a bool are "=1" and "=2", both setting the bool to 1 (true), and the 
> second one only if
> 
>    bool_variable = int_variable;
> 
> is always automatically converted to
> 
>    bool_variable = (bool) int_variable;
> 
> The rest of them make little or no sense for an operation on a bool, yet 
> the compiler gives not a hint of a problem.  For instance, there is no 
> point, ever, in incrementing a bool by 2 since the most it can change is 
> by 1.  Similarly logic on any but the lowest bit is pointless since they 
> will never be set.  Finally, the test "avar == 2" really should trigger 
> a warning since a bool can never be 2, and the 2 is not automatically 
> promoted to a bool (maybe the bool is promoted to an int?)  In any case 
> the test is clearly a programming error since it can never be true, and 
> the compiler can know that without having to reference any other piece 
> of code.  Seems to me that if this does not generate a warning then the 
> compiler should be doing it the other way around, consider the "2" as a 
> bool, thus true, and the result should be True.  (Which it isn't.)
> 
> What exactly are the rules for bool such that the behavior shown above 
> all makes sense (and is not worthy of a compiler warning)?

There are just two special rules that apply to expressions involving
_Bool operands:
6.3.1.1p1: "The [integer conversion] rank of _Bool shall be less than
the rank of all other standard integer types."

This means, in particular, it has a rank less than that of 'int'. As a
result, operands of type _Bool are promoted to 'int' in just about every
context, before an expression is evaluated. That's why _Bool is usable
just about anywhere that an 'int' is usable.
There are exceptions, such as sizeof(avar), which is not necessarily the
same as sizeof(int), but none of those exceptions come up in your code.
6.3.1.2p1: "When any scalar value is converted to _Bool, the result is 0
if the value compares equal to 0; otherwise, the result is 1." Note that
null pointers compare equal to 0, and NaNs do not.

Everything you've seen follows from those two rules.

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

#18971

Le 23/03/12 16:40, mathog a écrit :
> I just found out the hard way that the C99 "bool" type can result in
> some very hard to diagnose bugs. This problem came up in the context of
> a field in a structure which had been declared in a file "long ago and
> far away" and which I had not seen. From the usage in the file where the
> problem was found it looked like this value was an int, but it was a
> bool. As it turns out at least the gcc compiler (4.4.1) gives no
> warnings when bools are used in ways that are "int" like but make little
> or no sense for a bool.
>
> The rest of them make little or no sense for an operation on a bool, yet
> the compiler gives not a hint of a problem. For instance, there is no
> point, ever, in incrementing a bool by 2 since the most it can change is
> by 1.

I think you have an important point here. Bool is a logical value, not 
an arithmetic or floating point value. There is no sense in taking the 
square root of a bool, nor there is any sense in dividing a bool by any
integer: the result is always zero unless the other number is 1.

Treating boolean variables as integers is an error, and I think the 
standard should disallow arithmetic with booleans...

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

#18973

On Fri, 23 Mar 2012 21:45:38 +0100, jacob navia <jacob@spamsink.net>
wrote:

>Le 23/03/12 16:40, mathog a écrit :
>> I just found out the hard way that the C99 "bool" type can result in
>> some very hard to diagnose bugs. This problem came up in the context of
>> a field in a structure which had been declared in a file "long ago and
>> far away" and which I had not seen. From the usage in the file where the
>> problem was found it looked like this value was an int, but it was a
>> bool. As it turns out at least the gcc compiler (4.4.1) gives no
>> warnings when bools are used in ways that are "int" like but make little
>> or no sense for a bool.
>>
>> The rest of them make little or no sense for an operation on a bool, yet
>> the compiler gives not a hint of a problem. For instance, there is no
>> point, ever, in incrementing a bool by 2 since the most it can change is
>> by 1.
>
>I think you have an important point here. Bool is a logical value, not 
>an arithmetic or floating point value. There is no sense in taking the 
>square root of a bool, nor there is any sense in dividing a bool by any
>integer: the result is always zero unless the other number is 1.
>
>Treating boolean variables as integers is an error, and I think the 
>standard should disallow arithmetic with booleans...


Yet the language has always allowed the results of logical or
relational operators to be used arithmetically.  How do you define a
rule that continues to allow that but disallows the use of _Bools?

There are days when I think all implicit conversions are evil.
Unfortunately the clutter that approach causes is pretty painful.

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

#18974

Le 23/03/12 23:17, Robert Wessel a écrit :
> Yet the language has always allowed the results of logical or
> relational operators to be used arithmetically.  How do you define a
> rule that continues to allow that but disallows the use of _Bools?

The rule could be simply:

Only boolean operations are allowed with bools: or, and, xor, not. If 
you want to do arithmetic with bools you store that into an int (or
long double or whatever) and then you go on from there.

Or you make a cast.

There shouldn't be any *implicit* conversions.

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

#18975 — Re: c99 and the lack of warnings when int operations are applied to a bool

On 03/24/12 11:29 AM, jacob navia wrote:
> Le 23/03/12 23:17, Robert Wessel a écrit :
>> Yet the language has always allowed the results of logical or
>> relational operators to be used arithmetically.  How do you define a
>> rule that continues to allow that but disallows the use of _Bools?
>
> The rule could be simply:
>
> Only boolean operations are allowed with bools: or, and, xor, not. If
> you want to do arithmetic with bools you store that into an int (or
> long double or whatever) and then you go on from there.
>
> Or you make a cast.
>
> There shouldn't be any *implicit* conversions.

Isn't assigning a _Bool to an int an implicit conversion?

-- 
Ian Collins

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

#19012 — Re: c99 and the lack of warnings when int operations are applied to a bool

Le 23/03/12 23:48, Ian Collins a écrit :
> On 03/24/12 11:29 AM, jacob navia wrote:
>> Le 23/03/12 23:17, Robert Wessel a écrit :
>>> Yet the language has always allowed the results of logical or
>>> relational operators to be used arithmetically. How do you define a
>>> rule that continues to allow that but disallows the use of _Bools?
>>
>> The rule could be simply:
>>
>> Only boolean operations are allowed with bools: or, and, xor, not. If
>> you want to do arithmetic with bools you store that into an int (or
>> long double or whatever) and then you go on from there.
>>
>> Or you make a cast.
>>
>> There shouldn't be any *implicit* conversions.
>
> Isn't assigning a _Bool to an int an implicit conversion?
>

Yes it is, but I am speaking about arithmetic operations like
multiplication and division.

Those operations have no meaning with bools.


bool a,b;

a*b |  1  |  0 |
------------------
0   |  0  |  0 |
1   |  1  |  0 |

a/b is a division by zero if b is zero. If b is one,
then it is a NOP.

a/b |  1  |  0 |
------------------
0   |  0  | NAN|  <<< UB
1   |  1  | NAN|  <<<<UB



Mmmm substration looks like xor isn't it?

a-b |  1  |  0 |
------------------
0   |  1  |  0 |
1   |  0  |  1 |

Addition:

a+b |  1  |  0 |
------------------
0   |  1  |  0 |
1   |  1  |  1 |

This means that those operations with booleans are with VERY high
probability ERRORS.

And if you substitute in the truth tables integer values (ANY integer
values) the results are equally weird. There is no point in doing those
operations and they are simply errors.

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

#19022 — Re: c99 and the lack of warnings when int operations are applied to a bool

jacob navia wrote:
) Yes it is, but I am speaking about arithmetic operations like
) multiplication and division.
)
) Those operations have no meaning with bools.
)
)
) bool a,b;
)
) a*b |  1  |  0 |
) ------------------
) 0   |  0  |  0 |
) 1   |  1  |  0 |

In boolean arithmetic, multiplication is used as 'and'.

) a/b is a division by zero if b is zero. If b is one,
) then it is a NOP.
)
) a/b |  1  |  0 |
) ------------------
) 0   |  0  | NAN|  <<< UB
) 1   |  1  | NAN|  <<<<UB
)
)
)
) Mmmm substration looks like xor isn't it?
)
) a-b |  1  |  0 |
) ------------------
) 0   |  1  |  0 |
) 1   |  0  |  1 |

Hmm, 'xor' is usually denoted by a plus with a circle around it.

) Addition:
)
) a+b |  1  |  0 |
) ------------------
) 0   |  1  |  0 |
) 1   |  1  |  1 |

And addition is used as 'or'.

) This means that those operations with booleans are with VERY high
) probability ERRORS.

No, at least addition and multiplication are commonplace for boolean
algebra in mathematics.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#19023 — Re: c99 and the lack of warnings when int operations are applied to a bool

"Willem" <willem@toad.stack.nl> wrote in message
news:slrnjmto24.1v6r.willem@toad.stack.nl...
> jacob navia wrote:
> ) Yes it is, but I am speaking about arithmetic operations like
> ) multiplication and division.
> )
> ) Those operations have no meaning with bools.
> )
> )
> ) bool a,b;
> )
> ) a*b |  1  |  0 |
> ) ------------------
> ) 0   |  0  |  0 |
> ) 1   |  1  |  0 |
>
> In boolean arithmetic, multiplication is used as 'and'.
...
> And addition is used as 'or'.

Maybe. But 'and' and 'or' are also available, either as symbols (&& & || |)
or words.

And the symbol forms let you choose whether to use short-circuit evaluation
(&& ||) or not (& |).

Remember C also has small sets, in the form of integers (typically of 32 and 
64 bits). You can use bitwise operations (& |) on these sets, but trying to 
use * and + to do the same will result in something entirely different!

So it's best to apply the same thinking to individual bools.

(What *would* be useful would be int*bool, bool*double, etc. So A*bool is
either A, or zero. But a simple cast to int will achieve the same.)

> ) Mmmm substration looks like xor isn't it?
> )
> ) a-b |  1  |  0 |
> ) ------------------
> ) 0   |  1  |  0 |
> ) 1   |  0  |  1 |
>
> Hmm, 'xor' is usually denoted by a plus with a circle around it.

C has '^' (as well as 'xor'). However, subtraction is another integer 
operation that makes little sense for sets. A more useful notion of 
subtract, applied to individual bools, might be:

A B  A-B
--------
0 0  0
0 1  0
1 0  1
1 1  0

In an actual set, this would subtract those elements of B that also exist in 
A. (This is equivalent to ((A or B) xor B).) A normal subtraction won't 
work. Another reason to keep bool operations distinct.

-- 
Bartc

 

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

#19032 — Re: c99 and the lack of warnings when int operations are applied to a bool

"BartC" <bc@freeuk.com> writes:

> (What *would* be useful would be int*bool, bool*double, etc. So A*bool is
> either A, or zero. But a simple cast to int will achieve the same.)

The "would" suggests that this is not currently possible, but it is (and
no casts are needed).

-- 
Ben.

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

#19033 — Re: c99 and the lack of warnings when int operations are applied to a bool

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> "BartC" <bc@freeuk.com> writes:
>
>> (What *would* be useful would be int*bool, bool*double, etc. So A*bool is
>> either A, or zero. But a simple cast to int will achieve the same.)
>
> The "would" suggests that this is not currently possible, but it is (and
> no casts are needed).

It's possible if you're sure the bool only holds zero or one.

In practice, it is frequently safer to use 
 (bool ? A : 0)
which is only necessary because the bool does (in fact) typically have
the semantics of a larger type of integer
-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

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

#19035 — Re: c99 and the lack of warnings when int operations are applied to a bool

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> "BartC" <bc@freeuk.com> writes:
>>
>>> (What *would* be useful would be int*bool, bool*double, etc. So A*bool is
>>> either A, or zero. But a simple cast to int will achieve the same.)
>>
>> The "would" suggests that this is not currently possible, but it is (and
>> no casts are needed).
>
> It's possible if you're sure the bool only holds zero or one.
>
> In practice, it is frequently safer to use 
>  (bool ? A : 0)
> which is only necessary because the bool does (in fact) typically have
> the semantics of a larger type of integer

Are we talking about the same thing?  C's standard bool (a macro that
expands to _Bool) does not have the semantics of a larger integer type.

-- 
Ben.

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

#19036 — Re: c99 and the lack of warnings when int operations are applied to a bool

On 03/25/2012 05:14 PM, Ben Bacarisse wrote:
> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> "BartC" <bc@freeuk.com> writes:
>>>
>>>> (What *would* be useful would be int*bool, bool*double, etc. So A*bool is
>>>> either A, or zero. But a simple cast to int will achieve the same.)
>>>
>>> The "would" suggests that this is not currently possible, but it is (and
>>> no casts are needed).
>>
>> It's possible if you're sure the bool only holds zero or one.
>>
>> In practice, it is frequently safer to use 
>>  (bool ? A : 0)
>> which is only necessary because the bool does (in fact) typically have
>> the semantics of a larger type of integer
> 
> Are we talking about the same thing?  C's standard bool (a macro that
> expands to _Bool) does not have the semantics of a larger integer type.

It implicitly converts to int in most contexts, including all of the
contexts that have been the subject of this thread.  I think that's what
Lowell was referring to. The only specifically boolean semantics it has
is on conversion to _Bool.
-- 
James Kuyper

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

#19049

James Kuyper <jameskuyper@verizon.net> writes:

> On 03/25/2012 05:14 PM, Ben Bacarisse wrote:
>> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
>> 
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> "BartC" <bc@freeuk.com> writes:
>>>>
>>>>> (What *would* be useful would be int*bool, bool*double, etc. So A*bool is
>>>>> either A, or zero. But a simple cast to int will achieve the same.)
>>>>
>>>> The "would" suggests that this is not currently possible, but it is (and
>>>> no casts are needed).
>>>
>>> It's possible if you're sure the bool only holds zero or one.
>>>
>>> In practice, it is frequently safer to use 
>>>  (bool ? A : 0)
>>> which is only necessary because the bool does (in fact) typically have
>>> the semantics of a larger type of integer
>> 
>> Are we talking about the same thing?  C's standard bool (a macro that
>> expands to _Bool) does not have the semantics of a larger integer type.
>
> It implicitly converts to int in most contexts, including all of the
> contexts that have been the subject of this thread.  I think that's what
> Lowell was referring to. The only specifically boolean semantics it has
> is on conversion to _Bool.

This: "it's possible if you're sure the bool only holds zero or one" and
"bool [has] the semantics of a larger type of integer" only "typically"
rather than always, suggests that is not what was meant.

I think he was talking about a situation where you don't know whether
you have C99 bools or a pre-C99 implementation of a bool type and, in
that context, he makes a good point, but that's not what Jacob was
talking about and this not what I was commenting on.

-- 
Ben.

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

#19063

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> James Kuyper <jameskuyper@verizon.net> writes:
>
>> On 03/25/2012 05:14 PM, Ben Bacarisse wrote:
>>> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
>>> 
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> "BartC" <bc@freeuk.com> writes:
>>>>>
>>>>>> (What *would* be useful would be int*bool, bool*double, etc. So A*bool is
>>>>>> either A, or zero. But a simple cast to int will achieve the same.)
>>>>>
>>>>> The "would" suggests that this is not currently possible, but it is (and
>>>>> no casts are needed).
>>>>
>>>> It's possible if you're sure the bool only holds zero or one.
>>>>
>>>> In practice, it is frequently safer to use 
>>>>  (bool ? A : 0)
>>>> which is only necessary because the bool does (in fact) typically have
>>>> the semantics of a larger type of integer
>>> 
>>> Are we talking about the same thing?  C's standard bool (a macro that
>>> expands to _Bool) does not have the semantics of a larger integer type.
>>
>> It implicitly converts to int in most contexts, including all of the
>> contexts that have been the subject of this thread.  I think that's what
>> Lowell was referring to. The only specifically boolean semantics it has
>> is on conversion to _Bool.
>
> This: "it's possible if you're sure the bool only holds zero or one" and
> "bool [has] the semantics of a larger type of integer" only "typically"
> rather than always, suggests that is not what was meant.
>
> I think he was talking about a situation where you don't know whether
> you have C99 bools or a pre-C99 implementation of a bool type and, in
> that context, he makes a good point, but that's not what Jacob was
> talking about and this not what I was commenting on.

Yes. Apparently my brain has the capitalization wrong for the two
types, so I thought we were talking about different types. Sorry for
the (my) confusion.

-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

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

#19024

Willem <willem@toad.stack.nl> writes:

> No, at least addition and multiplication are commonplace for boolean
> algebra in mathematics.

Yes, but does the mathematical definition fit the 'C' one?

If we think of boolean's as lying in Z_2 (i.e. integers mod 2) we have

1+1 (mod 2) = 2(mod 2) = 0.  

With 'C' we have true + true => 1 + 1 => 2 => true.

C boolean arithmetic is not Z_2 arithmetic.

There's no point appealing to the commonplace in mathematics, if
applying that mathematical logic in C programs will result in incorrect
answers.

And if we want boolean logic operators, we've already got them in 
~, &, | and ^

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

#19025

Gareth Owen <gwowen@gmail.com> writes:

> Willem <willem@toad.stack.nl> writes:
>
>> No, at least addition and multiplication are commonplace for boolean
>> algebra in mathematics.
>
> Yes, but does the mathematical definition fit the 'C' one?
>
> If we think of boolean's as lying in Z_2 (i.e. integers mod 2) we have
>
> 1+1 (mod 2) = 2(mod 2) = 0.  
>
> With 'C' we have true + true => 1 + 1 => 2 => true.

That's what is called a Boolean ring, and is not what most people
consider to be Boolean algebra.  I am not saying that it's unreasonable
to assume this extension, but it is somewhat arbitrary.  You could just
treat + and * as analogs of OR and AND.

> C boolean arithmetic is not Z_2 arithmetic.

The discussion has been thrown off course a little by Jacob's assertion
that C should not do arithmetic on bool values.  In a very real sense
(if not a purely literal one) C does *not* do arithmetic on bool
values.  All of the operators mentioned (including & and |) operate on
int values and produce int results.  This means that it's not really
sensible to talk about "C Boolean arithmetic" without clarifying what is
meant.  I think most posters have interpreted this to be:

  (_Bool)(a OP b)

with OP being one of the arithmetic operators.  With this meaning, C's
Boolean arithmetic makes perfect sense.  a OP b on its own does not, but
then it's not an expression of type _Bool anyway.

Jacob later clarified that it's the automatic conversions that are the
problem, but he does not say what to do instead.  Lots of rules would
have to change just to permit

  _Bool a, b;
  /* ... */
  if (a | b) ...

to mean something.  Currently that's given a meaning by the "usual
arithmetic conversions".

> There's no point appealing to the commonplace in mathematics, if
> applying that mathematical logic in C programs will result in incorrect
> answers.
>
> And if we want boolean logic operators, we've already got them in 
> ~, &, | and ^

Small point:  I think looks '!' is better than '~' in this list.  '~'
produces wild int values that '!' does not.

-- 
Ben.

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

#19083

jacob navia <jacob@spamsink.net> writes:

> Le 23/03/12 23:48, Ian Collins a @C3{A9}crit :
>> On 03/24/12 11:29 AM, jacob navia wrote:
>>> Le 23/03/12 23:17, Robert Wessel a @C3{A9}crit :
>>>> Yet the language has always allowed the results of logical or
>>>> relational operators to be used arithmetically. How do you define a
>>>> rule that continues to allow that but disallows the use of _Bools?
>>>
>>> The rule could be simply:
>>>
>>> Only boolean operations are allowed with bools: or, and, xor, not. If
>>> you want to do arithmetic with bools you store that into an int (or
>>> long double or whatever) and then you go on from there.
>>>
>>> Or you make a cast.
>>>
>>> There shouldn't be any *implicit* conversions.
>>
>> Isn't assigning a _Bool to an int an implicit conversion?
>>
>
> Yes it is, but I am speaking about arithmetic operations like
> multiplication and division.
>
> Those operations have no meaning with bools.  [snip elaboration]

The problem is in thinking of bool (ie, _Bool) as some sort of
"logical" type.  It isn't.  Rather it is an integer type designed
to hold the value of C expression used to do selection (eg, with ?:
or &&).  Because the relational operators and so forth return 'int'
results (with value 0 or 1), they often are used in expressions
like other 'int' values (eg, by adding, multiplying, etc).  Since
bool (aka _Bool) is meant hold the result values of such operators,
it is natural that _Bool should behave the same way as an operator
generating said value, that is, as holding a regular integer value.
I suppose some people may not like that, but that's how C is, and
the semantics for _Bool reasonably reflects the purpose for which
it was created.

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

#18988

On Fri, 23 Mar 2012 23:29:03 +0100, jacob navia <jacob@spamsink.net>
wrote:

>Le 23/03/12 23:17, Robert Wessel a écrit :
>> Yet the language has always allowed the results of logical or
>> relational operators to be used arithmetically.  How do you define a
>> rule that continues to allow that but disallows the use of _Bools?
>
>The rule could be simply:
>
>Only boolean operations are allowed with bools: or, and, xor, not. If 
>you want to do arithmetic with bools you store that into an int (or
>long double or whatever) and then you go on from there.
>
>Or you make a cast.


So you're suggesting that:

  d += (b!=c);  /* works*/

but:

  bool a = (b!=c);  d+= a;  /* doesn't work */

Certainly doable, but not really keeping with the principal of least
surprise, at least for this case.  If you'd care to argue that neither
should be allowed, fine, I might just agree with you, but you're going
to break a heck of a lot of code if you actually make that change.


>There shouldn't be any *implicit* conversions.


But they're already all over C.  My first example above.  "somefloat
+= someint;",  "(somechar+1)", "somedouble + (someint * somelong)"...

When I said no implicit conversions, I meant to exclude *all* of
those.  IOW, if you want to add an int and a long, you need to
explicitly convert one or the other parameter (or convert them both to
a third type).  As I said, it results in a lot of clutter.

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

#19011

Le 24/03/12 07:15, Robert Wessel a écrit :
> On Fri, 23 Mar 2012 23:29:03 +0100, jacob navia<jacob@spamsink.net>
> wrote:
>
>> Le 23/03/12 23:17, Robert Wessel a écrit :
>>> Yet the language has always allowed the results of logical or
>>> relational operators to be used arithmetically.  How do you define a
>>> rule that continues to allow that but disallows the use of _Bools?
>>
>> The rule could be simply:
>>
>> Only boolean operations are allowed with bools: or, and, xor, not. If
>> you want to do arithmetic with bools you store that into an int (or
>> long double or whatever) and then you go on from there.
>>
>> Or you make a cast.
>
>
> So you're suggesting that:
>
>    d += (b!=c);  /* works*/
>
> but:
>
>    bool a = (b!=c);  d+= a;  /* doesn't work */

If d is an int, the integer is being modified, not the boolean, so
it is perfectly OK.

But if you write bool b=0; b += 5;

the boolean is being modified, that should be off limits or should give 
you a warning.

By the way, the lcc-win warns if you write

char m = 259;

or short f = 966776655;
Since any addition to a bool is mostly nonsense, it would be OK
to warn about it.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web