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 2 of 2 — ← Prev page 1 [2]

#19077

jacob navia wrote:

> 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.

My point exactly, even if a bool in some implementation is stored more 
or less the same way as an integer type, none of the integer operations 
should be applicable to it.  The problem is clearer if one thinks of the 
values of the bool as "True" and "False", as opposed to 0 or 1.  None of 
these have any meaning:

   True++
   True+10
   True/True
   True+False
   etc.

Code that performed those operations is broken.  Yet all of those are 
accepted without a hiccup at present.  This is different from the use of 
an int as a logical value, where, since in some contexts the variable 
might be used as an integer, and others as a logical value, all of the 
above are OK.

Consider even a simple assignment:

   bool b;
   int  i=25;
   b=i;

is actually:

   b= (i ? True : False);

and is not actually a direct assignment of the value of i to b.  In 
order to avoid difficult to find programming mistakes the explicit cast 
should be required:

   b = (bool) i;

and also going the other way

   i = (int) b;

This would let the compiler do its job of finding suspect code.  If the 
standard doesn't require it would still be a very useful compiler switch 
as something like:

   cc --req_cast_bool

Does the standard say that these situations cannot generate a warning??? 
  If not, then they should, at least optionally, as for instance if one 
used gcc's -Wall.

Regards,

David Mathog

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

#19082

mathog <dmathog@gmail.com> writes:
> jacob navia wrote:
>> 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.
>
> My point exactly, even if a bool in some implementation is stored more 
> or less the same way as an integer type, none of the integer operations 
> should be applicable to it.  The problem is clearer if one thinks of the 
> values of the bool as "True" and "False", as opposed to 0 or 1.  None of 
> these have any meaning:
>
>    True++
>    True+10
>    True/True
>    True+False
>    etc.
>
> Code that performed those operations is broken.  Yet all of those are 
> accepted without a hiccup at present.  This is different from the use of 
> an int as a logical value, where, since in some contexts the variable 
> might be used as an integer, and others as a logical value, all of the 
> above are OK.
>
> Consider even a simple assignment:
>
>    bool b;
>    int  i=25;
>    b=i;
>
> is actually:
>
>    b= (i ? True : False);
>
> and is not actually a direct assignment of the value of i to b.  In 
> order to avoid difficult to find programming mistakes the explicit cast 
> should be required:
>
>    b = (bool) i;
>
> and also going the other way
>
>    i = (int) b;
>
> This would let the compiler do its job of finding suspect code.  If the 
> standard doesn't require it would still be a very useful compiler switch 
> as something like:
>
>    cc --req_cast_bool
>
> Does the standard say that these situations cannot generate a warning??? 
>   If not, then they should, at least optionally, as for instance if one 
> used gcc's -Wall.

The standard *never* forbids warnings for anything.  It specifies
constructs for which an implementation must issue a diagnostic,
which may be either a warning or a fatal error, and it specifies
exactly one case where a translation unit must be rejected (#error),
but compilers can issue any additional warnings they like.

There are languages in which bool, or Boolean, is a completely
seperate type.  In Ada, for example, it's defined as an enumeration
type with some special properties (type Boolean is (False, True);),
and Ada enumeration types in general can't be mixed with integer
types.  For example, there's no predefined addition operator for
Boolean, or for any other enumeration type.

C *currently* defines _Bool as an unsigned integer type that can
hold the values 0 and 1.  There are some special rules regarding
conversions from other scalar types to _Bool, but you can do the
same implicit conversions between _Bool and any other arithmetic
type as you can for char, int, and so forth.

Personally, I like the Ada approach better.  But I'm not sure it
would have been practical to use the same approach in C.  It would
have required creating a whole new class of type, with _Bool as its
only member.  If it's a scalar type, you'd have to add special-case
restrictions to forbid certain implicit conversions; otherwise
"_Bool b = 0; b += 2;" would be perfectly legal (as it is now).
It's almost inevitable that some of those restrictions would prevent
programmers from doing some perfectly sensible things.

If you don't allow 0 and 1 to be assigned to a _Bool object,
requiring literal false and true instead, then you have an elementary
type for which 0 is not a valid value.  Currently, this:

    some_type obj = { 0 };

is valid for any object type; would it become invalid if some_type
is a structure one of whose members is a structure containing a
_Bool member?  Or would you have to permit 0 and 1 to be boolean
constants, just as 0 is a pointer constant?

What would be the required type of the condition in an if statement?
Forbidding integer, floating-point, and pointer expressions would
break most existing C programs.  Obviously we need to permit _Bool
conditions.  Is that a special case?  Do we permit an implicit
conversion from any scalar type to _Bool?  Does that conversion
occur everywhere (as it does now), or only in an expression used
as a condition?

I'm not saying that it would have been impossible to add a boolean
type that behaves as suggested, but I think it would have required
a lot more work to define it consistently, and I rather doubt that
the C committee (which consists of volunteers, remember) could have
afforded the time to do it.  They might have considered it if there
were existing practice, or if someone had submitted a proposal,
but as far as I know nobody did.

And I suggest that it's too late to fix it now without breaking
existing code.  There is existing code that applies the ++ operator
to boolean objects, expecting them to be set to a true value (that
goes back before C99, when the "boolean" object was probably an int).

If I were designing a C-like language from scratch today, I'd
probably make bool a distinct type without implicit conversions, and
require "if (ptr != NULL)" rather than "if (ptr)", and "if (n != 0)"
rather than "if (n)".  But we no longer have the luxury of doing that
-- and I'm sure a lot of people wouldn't like that approach anyway.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#19084

On 03/27/2012 12:53 PM, mathog wrote:
...
> My point exactly, even if a bool in some implementation is stored more 
> or less the same way as an integer type, none of the integer operations 
> should be applicable to it.  The problem is clearer if one thinks of the 
> values of the bool as "True" and "False", as opposed to 0 or 1.  None of 
> these have any meaning:
> 
>    True++
>    True+10
>    True/True
>    True+False
>    etc.
> 
> Code that performed those operations is broken.  Yet all of those are 
> accepted without a hiccup at present.  This is different from the use of 
> an int as a logical value, where, since in some contexts the variable 
> might be used as an integer, and others as a logical value, all of the 
> above are OK.
> 
> Consider even a simple assignment:
> 
>    bool b;
>    int  i=25;
>    b=i;
> 
> is actually:
> 
>    b= (i ? True : False);
> 
> and is not actually a direct assignment of the value of i to b.  In 
> order to avoid difficult to find programming mistakes the explicit cast 
> should be required:
> 
>    b = (bool) i;
> 
> and also going the other way
> 
>    i = (int) b;
> 
> This would let the compiler do its job of finding suspect code.  If the 
> standard doesn't require it would still be a very useful compiler switch 
> as something like:
> 
>    cc --req_cast_bool
> 
> Does the standard say that these situations cannot generate a warning???

The standard never prohibits warnings, it only mandates diagnostic
messages. A fully conforming compiler is free to warn about anything
it's makers want it to warn about. It can warn about the fact that you
used profanity in your program - it could also warn about the fact that
you did NOT use profanity in your program.

No diagnostic is mandated for any of the cases you describe, because
_Bool values are implicitly promoted to 'int', for which all of those
operations are permitted and reasonable. Whether the implicit promotion
is reasonable is another question.

>   If not, then they should, at least optionally, as for instance if one 
> used gcc's -Wall.

You can't ask gcc to warn if a _Bool value is used in an addition
expression, because that never happens - the _Bool value is promoted to
'int' before it is added.

You can ask the makers of gcc to implement a warning for all implicit
conversions of _Bool to other types. No such conversion occurs in most
contexts where use of a boolean value actually makes sense: sizeof,
_Alignof, &&, ||, !, the left operand of ?:, simple assignment when the
destination is of _Bool type, if(), while(), the second expression of
for(), and the return statement of a function declared as returning
_Bool. The main exceptions are ==, !=, and switch(), which all perform
the integer promotions on _Bool values.

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

#19955

On 3/27/2012 12:53 PM, mathog wrote:
> jacob navia wrote:
>
>> 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.
>
> My point exactly, even if a bool in some implementation is stored more
> or less the same way as an integer type, none of the integer operations
> should be applicable to it.

	bool expensive(), complicated(), long_winded();
	switch (4*expensive() + 2*complicated() + long_winded()) {
	case 0: ...
	case 1: ...
	case 2: ...
	case 3: ...
	case 4: ...
	case 5: ...
	case 6: ...
	case 7: ...
	}

I'll grant that this sort of situation doesn't arise all that often,
and I'll grant that there are other ways to write the logic (there's
usually more than one way to do something in C), but I think you're
going overboard in trying to legislate the pattern out of existence.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#19956

Le 26/04/12 13:57, Eric Sosman a écrit :
>
> bool expensive(), complicated(), long_winded();

With my proposal, your expression should be

  switch (4*(int)expensive() + 2*(int)complicated() + (int)long_winded())

An explicit cast makes the programmer intention clear.

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

#19957

On 04/26/2012 07:57 AM, Eric Sosman wrote:
> On 3/27/2012 12:53 PM, mathog wrote:
...
>> My point exactly, even if a bool in some implementation is stored more
>> or less the same way as an integer type, none of the integer operations
>> should be applicable to it.
> 
> 	bool expensive(), complicated(), long_winded();
> 	switch (4*expensive() + 2*complicated() + long_winded()) {
> 	case 0: ...
> 	case 1: ...
> 	case 2: ...
> 	case 3: ...
> 	case 4: ...
> 	case 5: ...
> 	case 6: ...
> 	case 7: ...
> 	}
> 
> I'll grant that this sort of situation doesn't arise all that often,
> and I'll grant that there are other ways to write the logic (there's
> usually more than one way to do something in C), but I think you're
> going overboard in trying to legislate the pattern out of existence.

If bool were a strictly logical type, on which no arithmetic could be
performed, that pattern would still be allowed, the syntax would just be
slightly more complicated:

(expensive()?4:0) + (complicated()?2:0) + (long_winded()?1:0)




-- 
James Kuyper

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

#19989

On 4/26/2012 9:09 AM, James Kuyper wrote:
> On 04/26/2012 07:57 AM, Eric Sosman wrote:
>> On 3/27/2012 12:53 PM, mathog wrote:
> ...
>>> My point exactly, even if a bool in some implementation is stored more
>>> or less the same way as an integer type, none of the integer operations
>>> should be applicable to it.
>>
>> 	bool expensive(), complicated(), long_winded();
>> 	switch (4*expensive() + 2*complicated() + long_winded()) {
>> 	case 0: ...
>> 	case 1: ...
>> 	case 2: ...
>> 	case 3: ...
>> 	case 4: ...
>> 	case 5: ...
>> 	case 6: ...
>> 	case 7: ...
>> 	}
>>
>> I'll grant that this sort of situation doesn't arise all that often,
>> and I'll grant that there are other ways to write the logic (there's
>> usually more than one way to do something in C), but I think you're
>> going overboard in trying to legislate the pattern out of existence.
>
> If bool were a strictly logical type, on which no arithmetic could be
> performed, that pattern would still be allowed, the syntax would just be
> slightly more complicated:
>
> (expensive()?4:0) + (complicated()?2:0) + (long_winded()?1:0)

     "I'll grant that there are other ways to write the logic," as
a person I deeply respect once wrote.

     Here's another example where arithmetic on bool is handy:

	const int days_in_month[2][12] = {
	    { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
	    { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
	};
	bool is_leap_year = ...;
	int month = ...;
	int days = days_in_month[is_leap_year][month - 1];

"One (int) cast and all's well," but don't forget the skeptical
glance one usually casts upon casts...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#19990

On 04/26/2012 09:29 PM, Eric Sosman wrote:
...
>      "I'll grant that there are other ways to write the logic," as
> a person I deeply respect once wrote.
> 
>      Here's another example where arithmetic on bool is handy:
> 
> 	const int days_in_month[2][12] = {
> 	    { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
> 	    { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
> 	};
> 	bool is_leap_year = ...;
> 	int month = ...;
> 	int days = days_in_month[is_leap_year][month - 1];
> 
> "One (int) cast and all's well," but don't forget the skeptical
> glance one usually casts upon casts...

In a hypothetical C-like language where bools were truly a separate
type, a cast to int would not be allowed. Instead, use
	(isleap_year ? 1 : 0).
-- 
James Kuyper

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

#19991

On 4/26/2012 9:58 PM, James Kuyper wrote:
> On 04/26/2012 09:29 PM, Eric Sosman wrote:
> ...
>>       "I'll grant that there are other ways to write the logic," as
>> a person I deeply respect once wrote.
>>
>>       Here's another example where arithmetic on bool is handy:
>>
>> 	const int days_in_month[2][12] = {
>> 	    { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
>> 	    { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
>> 	};
>> 	bool is_leap_year = ...;
>> 	int month = ...;
>> 	int days = days_in_month[is_leap_year][month - 1];
>>
>> "One (int) cast and all's well," but don't forget the skeptical
>> glance one usually casts upon casts...
>
> In a hypothetical C-like language where bools were truly a separate
> type, a cast to int would not be allowed. Instead, use
> 	(isleap_year ? 1 : 0).

     "I'll grant ..."  (Is there an echo in here?)

     The question that burns in my feeble brain is: "Why?"  What is
the benefit that a "No arithmetic on booleans" rule would bring?
In what way would the hypothetical C-like language be superior to
C-where-ints-work-just-fine-thanks?  I'm not inclined to accept
unsupported assertions like "Cleanliness is next to Godliness,"
but would attend to concrete, measurable, or estimatable advantages,
or to credible first-person anecdotes.

     So far, the only thing I've heard is the O.P.'s complaint
that the compiler allowed him to get himself in trouble by making
code changes without first understanding the code he was changing.

     Well, golly.

     If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#19996

On 04/26/2012 10:32 PM, Eric Sosman wrote:
> On 4/26/2012 9:58 PM, James Kuyper wrote:
...
>> In a hypothetical C-like language where bools were truly a separate
>> type, a cast to int would not be allowed. Instead, use
>> 	(isleap_year ? 1 : 0).
> 
>      "I'll grant ..."  (Is there an echo in here?)
> 
>      The question that burns in my feeble brain is: "Why?"  What is
> the benefit that a "No arithmetic on booleans" rule would bring?

It makes syntax errors out of constructs that are conceptually
meaningless, forcing the use of alternative constructs that say more
precisely what is actually going on. As such, it makes it easier to
detect erroneous constructs.

...
>      If you're looking for a language with seat belts, training
> wheels, airbags, and padded walls, C shouldn't be your first
> choice, and restrictions on arithmetic wouldn't change matters.

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.
-- 
James Kuyper

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

#19999

On Apr 26, 10:32 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 4/26/2012 9:58 PM, James Kuyper wrote:
>
>
>
>
>
>
>
>
>
> > On 04/26/2012 09:29 PM, Eric Sosman wrote:
> > ...
> >>       "I'll grant that there are other ways to write the logic," as
> >> a person I deeply respect once wrote.
>
> >>       Here's another example where arithmetic on bool is handy:
>
> >>        const int days_in_month[2][12] = {
> >>            { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
> >>            { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
> >>        };
> >>        bool is_leap_year = ...;
> >>        int month = ...;
> >>        int days = days_in_month[is_leap_year][month - 1];
>
> >> "One (int) cast and all's well," but don't forget the skeptical
> >> glance one usually casts upon casts...
>
> > In a hypothetical C-like language where bools were truly a separate
> > type, a cast to int would not be allowed. Instead, use
> >    (isleap_year ? 1 : 0).
>
>      "I'll grant ..."  (Is there an echo in here?)
>
>      The question that burns in my feeble brain is: "Why?"  What is
> the benefit that a "No arithmetic on booleans" rule would bring?

The benefit is that one avoids mixing semantics with types that other
people may use differently.  If you commonly use bool as an index to
an array, someone else may look at that and wonder, "What on earth is
that?  Why aren't you using an int or size_t because those are my
conceptual types to use as an index."  Either will get the job done,
but a careful choice of type can reduce the amount of confusion other
readers have to deal with, and provide more context to detect defects
in the presence of bugs.

Best regards,
John D.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web