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 Lanarcam <lanarcam1@yahoo.fr> - 2012-04-27 19:26 +0200
                      Re: c99 and the lack of warnings when int operations are applied to a bool Keith Thompson <kst-u@mib.org> - 2012-04-27 11:28 -0700
                        Re: c99 and the lack of warnings when int operations are applied to a bool Lanarcam <lanarcam1@yahoo.fr> - 2012-04-27 20:51 +0200
                        Re: c99 and the lack of warnings when int operations are applied to a bool ImpalerCore <jadill33@gmail.com> - 2012-04-27 12:17 -0700
                        Re: c99 and the lack of warnings when int operations are applied to a bool Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-28 09:17 +0200
                          Re: c99 and the lack of warnings when int operations are applied to a bool Keith Thompson <kst-u@mib.org> - 2012-04-28 13:26 -0700
                    Re: c99 and the lack of warnings when int operations are applied to a bool Willem <willem@toad.stack.nl> - 2012-04-27 18:11 +0000
                      Re: c99 and the lack of warnings when int operations are applied to a bool ImpalerCore <jadill33@gmail.com> - 2012-04-27 12:05 -0700
                      Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-04-27 15:32 -0400
                        Re: c99 and the lack of warnings when int operations are applied to a bool Willem <willem@toad.stack.nl> - 2012-04-27 20:16 +0000
                          Re: c99 and the lack of warnings when int operations are applied to a bool James Kuyper <jameskuyper@verizon.net> - 2012-04-27 16:45 -0400
                        Re: c99 and the lack of warnings when int operations are applied to a bool Rui Maciel <rui.maciel@gmail.com> - 2012-04-27 21:26 +0100
                        Re: c99 and the lack of warnings when int operations are applied to a bool Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-27 21:18 -0400
                    Re: c99 and the lack of warnings when int operations are applied to a bool Rui Maciel <rui.maciel@gmail.com> - 2012-04-27 21:33 +0100
                      Re: c99 and the lack of warnings when int operations are applied to a bool Keith Thompson <kst-u@mib.org> - 2012-04-27 15:36 -0700
                  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 3 of 3 — ← Prev page 1 2 [3]

#20012

On 04/27/2012 04:16 PM, Willem wrote:
> James Kuyper wrote:
> ) On 04/27/2012 02:11 PM, Willem wrote:
> )> James Kuyper wrote:
> )> ) On 04/26/2012 10:32 PM, Eric Sosman wrote:
> )> )>      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.
> )> 
> )> It also makes syntax errors out of constructs that are perfectly
> )> meaningful, forcing the use of needless extra boilerplate code
> )> that only serves to muddle what is actually going on.
> )
> ) I deny the fundamental meaningfullness of any code that treats a logical
> ) value as if it were numeric. What does true*3+false mean? It has a
> ) specific numeric meaning, one that almost any C programmer would know -
> ) but only because C arbitrarily gave it that meaning, not because it has
> ) any inherent meaning. It's intrinsically meaningless to multiply a truth
> ) value by 3.
> 
> My apologies, I had misunderstood the statement as: "No using arbitratry
>  expressions as booleans", but for the other way round, calculating with
> booleans, I almost(*) completely agree with you.


Well, I meant it both ways, even if I only addressed one direction, so
you can retain your disagreement. I also believe that treating a
numeric, pointer or character value as if they had a boolean meaning is
equally meaningless. They work only because they have been arbitrarily
given a meaning by the C language.

	void terminate(
		char *p,
		unsigned int n
	){
	    if(p && (n || p[n]))
	        p[n] = '\0';
	}

I've been programming in C since 1979, so it can be very difficult for
me to notice such things, but the meaning of that if() condition is a
result of the way C was designed, it's not something that the condition
actually clearly expresses.

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

#20010

James Kuyper wrote:

> I deny the fundamental meaningfullness of any code that treats a logical
> value as if it were numeric. What does true*3+false mean? 

It means what you intend it to mean.  For example, consider the following:

value = true*4 + true*2 + false;

This could very well be a way to define bitmask values.


> It has a
> specific numeric meaning, one that almost any C programmer would know -
> but only because C arbitrarily gave it that meaning, not because it has
> any inherent meaning. 

While risking going off on a tangent, I have to point out the fact that 
that's exactly how every single thing gets their meaning.


> It's intrinsically meaningless to multiply a truth
> value by 3.

<example>
const int option_1 = 1;
const int option_2 = 2;
const int option_1_and_2 = 3;

bool toggle_option_1_and_2 = get_input_from_the_user();

int program_options = toggle_option_1_and_2*option_1_and_2;
</example>


Rui Maciel

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

#20015

On 4/27/2012 3:32 PM, James Kuyper wrote:
> [...] It's intrinsically meaningless to multiply a truth
> value by 3.

     (I'd decided to abandon this thread on the grounds that it had
turned into a purely religious dispute, but some straight lines are
just too deliciously tempting.)

     (Ahem.)  The Bellman begs to differ.

http://www.literature.org/authors/carroll-lewis/the-hunting-of-the-snark/chapter-01.html

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

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

#20011

James Kuyper wrote:

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

I don't believe those barriers are needed for one reason alone: if you do 
want barriers, you are free to put them up yourself.  Just wrap any 
primitive data type with a struct and write your code around them as you see 
fit.

<example>
rui@Kubuntu:tmp$ cat example.c 
typedef struct Boolean
{
        int value;
} boolean_t;


int main(void)
{
        boolean_t b;
        int number = b*3;

        return 0;
}
rui@Kubuntu:tmp$ gcc example.c 
example.c: In function ‘main’:
example.c:10:16: error: invalid operands to binary * (have ‘boolean_t’ and 
‘int’)
</example>


Rui Maciel

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

#20013

Rui Maciel <rui.maciel@gmail.com> writes:
> James Kuyper wrote:
>>>"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.
>
> I don't believe those barriers are needed for one reason alone: if you do 
> want barriers, you are free to put them up yourself.  Just wrap any 
> primitive data type with a struct and write your code around them as you see 
> fit.
>
> <example>
> rui@Kubuntu:tmp$ cat example.c 
> typedef struct Boolean
> {
>         int value;
> } boolean_t;
>
>
> int main(void)
> {
>         boolean_t b;
>         int number = b*3;
>
>         return 0;
> }
> rui@Kubuntu:tmp$ gcc example.c 
> example.c: In function ‘main’:
> example.c:10:16: error: invalid operands to binary * (have ‘boolean_t’ and 
> ‘int’)
> </example>

The cost of those barriers is massive inconvenience, and the compiler
can enforce restrictions for you only in some cases.

    boolean_t b;
    int number;
    if (b) { ... }       /* error */
    if (b.value) { ... } /* ok */
    if (num) { ... }     /* error not caught by compiler */

    boolean_t x = ...;
    boolean_t y = ...;
    boolean_t x_or_y = (boolean_t){ x.value || y.value };

The C language just doesn't have the ability to define a distinct
boolean type that works the way some of us might like.

(If you don't think having such a type is worthwhile in the first place,
then the disadvantages are irrelevant.)

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

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

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

csiph-web