Request for warnings on implicit bool to int conversions

Request for warnings on implicit bool to int conversions

[mathog]

The C99 bool data type, and the similar type in C++, currently (v 
4.5.2) do not generate
warnings for any of these sorts of operations:

bool b;

   b = 3;
   b++;
   b += 2;
   if(b == 3)
   etc.

This can lead to a lot of hidden mischief because a variable declared 
far away may look like
an integer, but it acts like a bool.  It would be nice if there was a

   -Wimplicit_bool

that was enabled in -Wall which complained about these sorts of 
operations.  In particular
it would warn any time a bool was implicitly promoted to an int.

This issued was recently discussed in newsgroup comp.lang.c under the 
subject:
  c99 and the lack of warnings when int operations are applied to a bool

Thank you,

David Mathog
mathog@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: Request for warnings on implicit bool to int conversions

[Paolo Carlini]

Hi,
> It would be nice if there was a
>
>   -Wimplicit_bool
>
> that was enabled in -Wall which complained about these sorts of 
> operations.  In particular
> it would warn any time a bool was implicitly promoted to an int.
first blush your message should be a Bugzilla PR, this way the request 
doesn't risk to get lost and knowledgeable people could carefully 
analyze it in due course.

Thanks,
Paolo.

Re: Request for warnings on implicit bool to int conversions

[Gabriel Dos Reis]

> Hi,
>>
>> It would be nice if there was a
>>
>>  -Wimplicit_bool
>>
>> that was enabled in -Wall which complained about these sorts of
>> operations.  In particular
>> it would warn any time a bool was implicitly promoted to an int.
>

I am trying to understand what the real issue is here.  Do you want
-Wimplicit-char-to-int to?  -Wimplicit-short-to-int?  If not, why?
where to stop?

Re: Request for warnings on implicit bool to int conversions

[Russ Allbery]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> I am trying to understand what the real issue is here.  Do you want
> -Wimplicit-char-to-int to?  -Wimplicit-short-to-int?  If not, why?
> where to stop?

I think it's more about conversion *to* bool than from bool, and it
catches places where code has been partly converted to bool (generally
because it predated C99) but the error conversion wasn't done properly.
For example, while returning true or false is common, returning 0 or -1 as
a boolean return value where 0 is success is also common (as with UNIX
library interfaces).  If someone messes up such a conversion and has a:

    status = -1;

somewhere, they get entirely the wrong result if status becomes a bool.
This warning would pick up cases like that.

The warnings about doing things like:

    bool b = true;
    b++;
    b += 3;

are somewhat akin to the warnings about doing arithmetic on void *
pointers -- code like that is possibly a sign that there's something
flawed with the algorithm and it should be rewritten to treat booleans as
actual booleans.  (For example, b++ could easily wrap, and unexpectedly
fast depending on the size of bool on a platform.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Request for warnings on implicit bool to int conversions

[Gabriel Dos Reis]

On Tue, Mar 27, 2012 at 9:20 PM, Russ Allbery <rra@stanford.edu> wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
>> I am trying to understand what the real issue is here.  Do you want
>> -Wimplicit-char-to-int to?  -Wimplicit-short-to-int?  If not, why?
>> where to stop?
>
> I think it's more about conversion *to* bool than from bool,

I can easily see why an implicit conversion from int to bool might cause
a problem, even if that is what the language standard mandates -- just
look at the most common misuses of strcmp.  But, that is not what the proposer
requested, which got me scratching my head.

-- Gaby

Re: Request for warnings on implicit bool to int conversions

[Russ Allbery]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> I can easily see why an implicit conversion from int to bool might cause
> a problem, even if that is what the language standard mandates -- just
> look at the most common misuses of strcmp.  But, that is not what the
> proposer requested, which got me scratching my head.

Yeah.  But I suspect it was a mistaken statement.  The subject line from
the referenced comp.lang.c thread was:

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

which I think is best caught by the conversion *to* bool when the result
is stored, rather than the conversion *from* bool to perform the
operation.

I could see the other direction being marginally helpful in catching
people adding bools together, which may not make a lot of sense, but it
doesn't seem as likely to cause bugs.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Request for warnings on implicit bool to int conversions

[Russ Allbery]

Russ Allbery <rra@stanford.edu> writes:

> Yeah.  But I suspect it was a mistaken statement.  The subject line from
> the referenced comp.lang.c thread was:

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

> which I think is best caught by the conversion *to* bool when the result
> is stored, rather than the conversion *from* bool to perform the
> operation.

I've just briefly reviewed the thread, and it was about both, including
some discussion of warning about any operation that promotes a bool to
some other integer type, on the grounds that a bool would ideally be
treated as a special enumeration that didn't behave like an integer.
(With others pointing out that that isn't the programming language that we
have, as appealing as it might have been if designing C from scratch.)

But I think most of the *practical* problems would be caught by warning
about the implicit integer conversion to bool, if there's a way to wedge
that warning into the language.  (I suspect it might be hard because the
integer conversion may happen under the hood in lots of places that people
don't expect, but I don't know much about the internals.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Request for warnings on implicit bool to int conversions

[Franz Sirl]

Am 2012-03-28 00:43, schrieb mathog:
> The C99 bool data type, and the similar type in C++, currently (v 4.5.2)
> do not generate
> warnings for any of these sorts of operations:
>
> bool b;
>
> b = 3;
> b++;
> b += 2;
> if(b == 3)

The last one is PR 44077.

Franz

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[Michael Witten]

On Tue, 27 Mar 2012 19:20:52 -0700, Russ Allbery wrote:

> (For example, b++ could easily wrap, and unexpectedly fast
> depending on the size of bool on a platform.)

Actually, it would appear that a bool (or a _Bool) can't wrap
on increment, but it CAN wrap on decrement (and strangely,
when the operand is a bool, C++ not only deprecates the prefix
and postfix `++' operators, but also forbids the prefix and
postfix `--' operators; this is particularly strange given
that similar semantics are still to be had with the `+='
and `-=' compound assignments).  

I'm going to deal with the prefix operators rather than the
postfix operators, in order to concentrate on the value that
is newly assigned to the variable in question.

Firstly, the C++ standard is very explicit and concise.
According to C++11.5.3.2 "Increment and decrement":

  1 The operand of prefix ++ is modified by adding 1, or set to
    true if it is bool (this use is deprecated). The operand
    shall be a modifiable lvalue. The type of the operand shall
    be an arithmetic type or a pointer to a completely-defined
    object type. The result is the updated operand; it is an
    lvalue, and it is a bit-field if the operand is a bit-field.
    If x is not of type bool, the expression ++x is equivalent
    to x+=1...

  2 The operand of prefix -- is modified by subtracting 1. The
    operand shall not be of type bool. The requirements on the
    operand of prefix -- and the properties of its result are
    otherwise the same as those of prefix ++...

As for C99, indulge me for a moment.

According to C99.6.5.3.1 "Prefix increment and decrement operators":

    ...

  2 The value of the operand of the prefix ++ operator is
    incremented. The result is the new value of the operand after
    incrementation. The expression ++E is equivalent to (E+=1).
    See the discussions of additive operators and compound
    assignment for information on constraints, types, side
    effects, and conversions and the effects of operations on
    pointers.

    ...

and according to C99.6.5.16.2 "Compound Assignment":

    ...

  3 A compound assignment of the form E1 op= E2 differs from the
    simple assignment expression E1 = E1 op (E2) only in that the
    lvalue E1 is evaluated only once.


and according to C99.6.5.6 "Additive operators":

    ...

  2 For addition, either both operands shall have arithmetic
    type, or one operand shall be a pointer to an object type
    and the other shall have integer type. (Incrementing is
    equivalent to adding 1.)

    ...

  4 If both operands have arithmetic type, the usual arithmetic
    conversions are performed on them.

  5 The result of the binary + operator is the sum of the
    operands.

    ...

and according to C99.6.2.5 "Types":

    ...

  6 ... The type _Bool and the unsigned integer types that correspond
    to the standard signed integer types are the standard unsigned
    integer types... The standard and extended unsigned integer types
    are collectively called unsigned integer types.

    ...

 17 The type char, the signed and unsigned integer types, and the
    enumerated types are collectively called integer types...

 18 Integer and floating types are collectively called arithmetic
    types.


    ...

and according to C99.6.3.1.8 "Usual arithmetic conversions":

  1 ...
    
        Otherwise, the integer promotions are performed on both
        operands. Then the following rules are applied to the
        promoted operands:
    
            If both operands have the same type, then no further
            conversion is needed.

            ...
        ...
    ...

and according to C99.6.3.1.1 "Boolean, characters, and integers"

 2  ... If an int can represent all values of the original
    type, the value is converted to an int; otherwise, it is
    converted to an unsigned int. These are called the integer
    promotions...

and according to C99.6.3.1.2 "Boolean type":

  1 When any scalar value is converted to _Bool,
    the result is 0 if the value compares equal
    to 0; otherwise, the result is 1.

and according to C99.7.16 "Boolean type and values <stdbool.h>":

  1 The header <stdbool.h> defines four macros.

  2 The macro

        bool

    expands to _Bool.

    ...

So, the prefix `++' operator expression in the following:

  bool b = 1;
  ++b;

should assign to `b' the value of the following expression:

  (bool)((int)b + (int)1)
  (bool)((int)1 + (int)1)
  (bool)2
  1

That is, the value of `b' should remain `1', which is corroborated
when the following program:

  #include <stdbool.h>
  int main(void)
  {
    bool b = 1;
    for (;;) ++b;
  }

is compiled with:

  gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c

thereby yield the following GIMPLE representation:

  main ()
  {
    int D.1090;

    {
      _Bool b;

      b = 1;
      <D.1088>:
      b = 1;
      goto <D.1088>;
    }
    D.1090 = 0;
    return D.1090;
  }

As you can see, the loop simply keeps assigning to `b' the value `1':

      <D.1088>:
      b = 1;
      goto <D.1088>;

As for decrementing a _Bool, according to C99.6.5.3.1
"Prefix increment and decrement operators":

    The prefix -- operator is analogous to the prefix ++
    operator, except that the value of the operand is
    decremented.

So, the prefix `--' operator expression in the following:

  #include <stdbool.h>
  bool b = 0;
  --b;

should assign to `b' the value of the following expression:

  (bool)((int)b - (int)1)
  (bool)((int)0 - (int)1)
  (bool)-1
  1

That is, the value of `b' can wrap on decrement, which is
corroborated when the following program:

  #include <stdbool.h>
  int main(void)
  {
    bool b = 0;
    for (;;) --b;
  }

is compiled with:

  gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c

thereby yield the following GIMPLE representation:

  main ()
  {
    int D.1090;
  
    {
      _Bool b;
  
      b = 0;
      <D.1088>:
      b = !b;
      goto <D.1088>;
    }
    D.1090 = 0;
    return D.1090;
  }

As you can see, the loop simply keeps assigning to `b' the logical
negation of `b':

      <D.1088>:
      b = !b;
      goto <D.1088>;

Similar arguments can be made for `b+=1' and `b-=1' (even for C++);
however, the GIMPLE representation is sometimes not as optimized:
For `b+=1' (and similarly for `b-=1'), gcc produces the following
more general computation:

      <D.1088>:
      D.1090 = (int) b;
      D.1091 = D.1090 + 1;
      b = D.1091 != 0;
      goto <D.1088>;

Also, while g++ does the simple logical negation for `b-=1', it
instead forgos a simple assignment of `1' in favor of the following
bizarre gymnastics for `b+=1':

      <D.983>:
      D.984 = (int) b;
      b = D.984 != -1;
      goto <D.983>;

Maybe there's room for a patch?

Anyway, I'm done with my mental pleasuring for the day.

Ta ta!
Michael Witten

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[mathog]

On 28-Mar-2012 12:18, Michael Witten wrote:

Wow, that was thorough!

The behavior of b++ vs. b-- was interesting, but is yet one more reason 
why the warning is needed.  Since
b-- is equivalent to !b, and b++ is equivalent to 1, if that action is 
intended, there is no reason to
use either the increment or decrement operators on a bool.

>   gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c

That's a trick worth knowing. Thanks!
Ran that on a test program and in every case but one there was an 
implicit

    (int) b

on sections of code which I though should generate warnings.  (Math ops 
on bools, comparison operations of
bool with ints.) The one exception in that little program was:

   b=2;

which came out as

   b=1;

In that case the compiler must have performed an implicit

   1 = (bool) 2

Also these forms all generated implicit int conversions

   if(b==1)
   if(b==2)
   if(b==0)

whereas

   if(b)

did not.

So let's turn this around.  If the compiler warned on all implicit 
conversions of bool <-> int,
what program lines would it warn on that it shouldn't?  It would warn 
on:

   if(b==1)
   if(b==0)

but I would argue that line is inappropriate for a bool type, and 
should be written as:

   if(b)

With two bool variables, this also did not generate an implicit 
conversion (and so would not warn,
which is appropriate):

   if(b1 || b2)

Whereas this less preferred form would have generated an implicit (int) 
[and a well deserved warning]

   if(b1 + b2)

Regards,

David Mathog
mathog@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[Michael Witten]

On Wed, Mar 28, 2012 at 20:30, mathog <mathog@caltech.edu> wrote:

> Since b-- is equivalent to [assigning] !b,
> and b++ is equivalent to [assigning] 1, if
> that action is intended, there is no reason
> to use either the increment or decrement
> operators on a bool.

However, it seems to me that toggling the value with the idiom:

 --b;

is aesthetically preferable to the more elaborate:

  b = !b;

In fact, I've seen at least one person make this complaint in
freenode's ##c++ IRC channel.

Given the potential usefulness of `--b' and the relative uselessness
of `++b', it would seem more practical for the C++ standard to have
deprecated (if not allowed) `--b' and instead forbidden `++b' (rather
than the other way around).

Re: Request for warnings on implicit bool to int conversions

[Michael Witten]

On Wed, Mar 28, 2012 at 20:30, David Mathog wrote:

> ...
>
>>  gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c
>
>
> That's a trick worth knowing. Thanks!
> Ran that on a test program and in every case but one there was an implicit
>
>   (int) b
>
> on sections of code which I though should generate warnings.  (Math ops on
> bools, comparison operations of
> bool with ints.) The one exception in that little program was:
>
>  b=2;
>
> which came out as
>
>  b=1;
>
> In that case the compiler must have performed an implicit
>
>  1 = (bool) 2
>
> Also these forms all generated implicit int conversions
>
>  if(b==1)
>  if(b==2)
>  if(b==0)
>
> whereas
>
>  if(b)
>
> did not.
>
> So let's turn this around.  If the compiler warned on all implicit
> conversions of bool <-> int,
> what program lines would it warn on that it shouldn't?  It would warn on:
>
>  if(b==1)
>  if(b==0)
>
> but I would argue that line is inappropriate for a bool type, and should be
> written as:
>
>  if(b)
>
> With two bool variables, this also did not generate an implicit conversion
> (and so would not warn,
> which is appropriate):
>
>  if(b1 || b2)
>
> Whereas this less preferred form would have generated an implicit (int) [and
> a well deserved warning]
>
>  if(b1 + b2)


Your suggestion is probably a good idea, but as with all good ideas,
it will probably not get implemented because most people don't care.

Therefore, I'd suggest writing a patch and submitting it; people will
no doubt be a lot more receptive when you convey your thoughts in
hard-nosed, precise code, ESPECIALLY because that means the work has
already been done!

Sincerely,
Michael Witten

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[mathog]

On 28-Mar-2012 15:20, Michael Witten wrote:

> However, it seems to me that toggling the value with the idiom:
>
>  --b;
>
> is aesthetically preferable to the more elaborate:
>
>   b = !b;

Aesthetically, not logically.  Neither of these makes the least bit of 
sense:

    one less than False
    one less than True

A better solution for the aesthetics would have been (it is a bit late 
now) to implement the missing unary negation operator:

   !!b;  //T->F, F->T

That operator would save even more program characters for the other int 
types, where it would be equivalent to:

   (i==0 ? 1 : 0);


Regards,

David Mathog
mathog@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[David Brown]

On 29/03/2012 00:52, mathog wrote:
> On 28-Mar-2012 15:20, Michael Witten wrote:
>
>> However, it seems to me that toggling the value with the idiom:
>>
>> --b;
>>
>> is aesthetically preferable to the more elaborate:
>>
>> b = !b;
>
> Aesthetically, not logically. Neither of these makes the least bit of
> sense:
>
> one less than False
> one less than True
>
> A better solution for the aesthetics would have been (it is a bit late
> now) to implement the missing unary negation operator:
>
> !!b; //T->F, F->T
>

You can't do that, because "!!" is already a useful operator on integers 
- it turns anything non-zero into 1 while leaving 0 alone, and is 
effectively an "int to bool" conversion operator.

> That operator would save even more program characters for the other int
> types, where it would be equivalent to:
>
> (i==0 ? 1 : 0);
>
>
> Regards,
>
> David Mathog
> mathog@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[mathog]

On 29-Mar-2012 03:20, David Brown wrote:
> On 29/03/2012 00:52, mathog wrote:

>> A better solution for the aesthetics would have been (it is a bit 
>> late
>> now) to implement the missing unary negation operator:
>>
>> !!b; //T->F, F->T
>>
>
> You can't do that, because "!!" is already a useful operator on
> integers - it turns anything non-zero into 1 while leaving 0 alone,
> and is effectively an "int to bool" conversion operator.

Right, hence the "a bit late now".

(I'm going to use "unary operator" for the rest of this to mean 
operations like ++, an operator that
changes the value of the operand all by itself.  There is some other 
technical term to distinguish that
from a unary "-", for instance, but I have long since forgotten what it 
is.)

I understand we aren't likely to ever see !! as a unary operator 
because of backwards
compatibility issues.  Since unary not is an obvious thing to have 
added to C99 along with
bool, my guess is that they couldn't figure a way to squeeze it in 
without stepping on !!
or something else still needed for backwards compatibility.

This highlights the problem with defining unary operators by repetition 
of single characters,
rather than by using a special symbol to indicate all of the unary 
operators, something like

   i@+ , i@- instead of i++, i--
   +@i , -@i instead if ++i, --i

and so forth, which would have allowed for unary variants of more 
operators. Including those not
considered at the time the language was first constructed. Here:  !@b 
and b@!, but also for
~, for instance.  We are all used to "++" now, but if you think about 
it
"add twice" is not a natural synonym for "increment", whereas 
<var><unary operator symbol><plus> is.

Anyway, this ship sailed a long, long, long time ago.

Regards,

David Mathog
mathog@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech