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

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

Is bool no longer a primitive data type of C/C++ ?

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

Contents

  Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 10:31 -0600
    Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 17:35 +0100
      Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 10:39 -0600
        Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 17:55 +0100
        Re: Is bool no longer a primitive data type of C/C++ ? guinness.tony@gmail.com - 2020-11-02 09:00 -0800
        Re: Is bool no longer a primitive data type of C/C++ ? Leo <usenet@gkbrk.com> - 2020-11-03 19:50 +0300
          Re: Is bool no longer a primitive data type of C/C++ ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-03 12:43 -0500
      Re: Is bool no longer a primitive data type of C/C++ ? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-11-02 17:48 +0100
        Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 10:50 -0600
          Re: Is bool no longer a primitive data type of C/C++ ? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-11-02 10:35 -0700
            Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 12:17 -0600
            Re: Is bool no longer a primitive data type of C/C++ ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-02 14:03 -0500
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 13:05 -0600
    Re: Is bool no longer a primitive data type of C/C++ ? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-11-02 16:50 +0000
      Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 11:07 -0600
        Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 18:08 +0100
          Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 11:11 -0600
            Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 18:13 +0100
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 11:25 -0600
        Re: Is bool no longer a primitive data type of C/C++ ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-02 17:22 +0000
          Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 11:26 -0600
          Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 11:38 -0600
            Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 19:01 +0100
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 12:19 -0600
              Re: Is bool no longer a primitive data type of C/C++ ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-11-02 12:19 -0800
                Re: Is bool no longer a primitive data type of C/C++ ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-29 00:09 -0800
                  Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-29 13:41 +0100
            Re: Is bool no longer a primitive data type of C/C++ ? Richard Damon <Richard@Damon-Family.org> - 2020-11-02 13:18 -0500
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 13:06 -0600
            Re: Is bool no longer a primitive data type of C/C++ ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-11-02 11:18 -0800
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 13:42 -0600
                Re: Is bool no longer a primitive data type of C/C++ ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-11-02 12:39 -0800
                  Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 15:08 -0600
                  Re: Is bool no longer a primitive data type of C/C++ ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-29 00:14 -0800
                    Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-29 13:53 +0100
                      Re: Is bool no longer a primitive data type of C/C++ ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-29 13:18 +0000
                        Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-29 16:16 +0100
                        Re: Is bool no longer a primitive data type of C/C++ ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-29 17:53 -0800
                      Re: Is bool no longer a primitive data type of C/C++ ? Richard Damon <Richard@Damon-Family.org> - 2020-11-29 08:19 -0500
                        Re: Is bool no longer a primitive data type of C/C++ ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-29 17:42 -0800
            Re: Is bool no longer a primitive data type of C/C++ ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-02 20:42 +0000
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 15:15 -0600
              Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-02 23:04 +0100
                Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 16:24 -0600
                Re: Is bool no longer a primitive data type of C/C++ ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-02 22:40 +0000
                Re: Is bool no longer a primitive data type of C/C++ ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-11-02 16:23 -0800
              Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 17:32 -0600
            Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-02 23:02 +0100
    Re: Is bool no longer a primitive data type of C/C++ ? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-11-02 09:56 -0700
      Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 18:05 +0100
        Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 11:08 -0600
          Re: Is bool no longer a primitive data type of C/C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 18:14 +0100
            Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 12:17 -0600
              Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-02 22:41 +0100
      Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-02 22:48 +0100
        Re: Is bool no longer a primitive data type of C/C++ ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-11-02 16:05 -0800
          Re: Is bool no longer a primitive data type of C/C++ ? olcott <NoOne@NoWhere.com> - 2020-11-02 18:45 -0600
          Re: Is bool no longer a primitive data type of C/C++ ? David Brown <david.brown@hesbynett.no> - 2020-11-03 11:35 +0100
    Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-02 19:03 +0100
      Re: Why macro ? scott@slp53.sl.home (Scott Lurndal) - 2020-11-02 19:05 +0000
        Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 07:41 +0100
          Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-03 11:38 +0100
            Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 12:39 +0100
              Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-03 13:10 +0100
                Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 13:23 +0100
                  Re: Why macro ? Bo Persson <bo@bo-persson.se> - 2020-11-03 13:45 +0100
                    Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 14:26 +0100
                      Re: Why macro ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-03 05:46 -0800
                        Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 15:10 +0100
                      Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-03 15:49 +0100
                        Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 15:56 +0100
                          Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-03 17:25 +0100
                            Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 17:29 +0100
                              Re: Why macro ? scott@slp53.sl.home (Scott Lurndal) - 2020-11-03 17:12 +0000
                                Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 18:15 +0100
                                  Re: Why macro ? red floyd <no.spam.here@its.invalid> - 2020-11-04 07:12 -0800
                                    Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-04 16:33 +0100
                                Re: Why macro ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-03 09:22 -0800
                            Re: Why macro ? Bart <bc@freeuk.com> - 2020-11-03 17:13 +0000
                              Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-03 20:07 +0100
                              Re: Why macro ? Juha Nieminen <nospam@thanks.invalid> - 2020-11-04 13:41 +0000
                            Re: Why macro ? Juha Nieminen <nospam@thanks.invalid> - 2020-11-04 13:32 +0000
                              Re: Why macro ? Richard Damon <Richard@Damon-Family.org> - 2020-11-04 08:59 -0500
                                Re: Why macro ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-04 06:01 -0800
                                Re: Why macro ? Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-11-04 17:11 +0100
                                  Re: Why macro ? Richard Damon <Richard@Damon-Family.org> - 2020-11-04 20:33 -0500
                              Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-04 16:44 +0100
                          Re: Why macro ? Richard Damon <Richard@Damon-Family.org> - 2020-11-03 12:37 -0500
                            Re: Why macro ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-03 10:42 -0800
                              Re: Why macro ? scott@slp53.sl.home (Scott Lurndal) - 2020-11-03 19:43 +0000
                                Re: Why macro ? David Brown <david.brown@hesbynett.no> - 2020-11-04 09:20 +0100
          Re: Why macro ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-03 03:07 -0800
            Re: Why macro ? Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-03 12:40 +0100
              Re: Why macro ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-03 04:02 -0800
    Re: Is bool no longer a primitive data type of C/C++ ? megonsara11@gmail.com - 2020-11-06 20:37 -0800

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#156373

On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> If bool is not a native type in C then they must have changed this at
>> some point after K&R C. Exactly when was this changed?
> 
> K&R C never had bool.  The second edition of K&R is essentially the same
> as the first ANSI and ISO standard, often called C90.
> 
> _Bool (and stdbool.h) were introduced in C99.
> 

Good answer. It solves my problem.

-- 
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#156375

On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> If bool is not a native type in C then they must have changed this at
>> some point after K&R C. Exactly when was this changed?
> 
> K&R C never had bool.  The second edition of K&R is essentially the same
> as the first ANSI and ISO standard, often called C90.
> 
> _Bool (and stdbool.h) were introduced in C99.
> 

Apparently this works on older compilers:
enum Boolean{true, false};
typedef enum Boolean bool;


-- 
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#156376

> Apparently this works on older compilers:
> enum Boolean{true, false};
> typedef enum Boolean bool;

enum has the size of an int, which would match the size
of a comparison result. _Bool and bool usually have the
size of a char.

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

#156381

On 11/2/2020 12:01 PM, Bonita Montero wrote:
>> Apparently this works on older compilers:
>> enum Boolean{true, false};
>> typedef enum Boolean bool;
> 
> enum has the size of an int, which would match the size
> of a comparison result. _Bool and bool usually have the
> size of a char.
> 

Also I am not sure how well assignment would work with the typedef 
version:   bool X = 5 > 7; // does compile

-- 
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#156389

On Monday, November 2, 2020 at 1:01:31 PM UTC-5, Bonita Montero wrote:
> > Apparently this works on older compilers: 
> > enum Boolean{true, false}; 
> > typedef enum Boolean bool;
> enum has the size of an int, which would match the size 
> of a comparison result. _Bool and bool usually have the 
> size of a char.

I think you may be thinking of C++, where the underlaying type for
enumerated types defaults to 'int'. However, this is also cross-posted
 to comp.lang.c.

In C, "An identifier declared as an enumeration constant has type int."
(6.4.4.3p2), and "The expression that defines the value of an
enumeration constant shall be an integer constant expression that has a
value representable as an int." (6.7.2.2p2). However, "Each enumerated
type shall be compatible with char, a signed integer type, or an
unsigned integer type. The choice of type is implementation-defined
..." (6.7.2.2p3). There is no requirement that the compatible integer
type be "int". It could be char, and I think there's a pretty good
chance that it will be in this case.

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

#156799

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Monday, November 2, 2020 at 1:01:31 PM UTC-5, Bonita Montero wrote:
>
>>> Apparently this works on older compilers:
>>> enum Boolean{true, false};
>>> typedef enum Boolean bool;
>>
>> enum has the size of an int, which would match the size
>> of a comparison result.  _Bool and bool usually have the
>> size of a char.
>
> I think you may be thinking of C++, where the underlaying type for
> enumerated types defaults to 'int'.  However, this is also cross-posted
>  to comp.lang.c.
>
> In C, "An identifier declared as an enumeration constant has type int."
> (6.4.4.3p2), and "The expression that defines the value of an
> enumeration constant shall be an integer constant expression that has a
> value representable as an int."  (6.7.2.2p2).  However, "Each enumerated
> type shall be compatible with char, a signed integer type, or an
> unsigned integer type.  The choice of type is implementation-defined
> ..."  (6.7.2.2p3).  There is no requirement that the compatible integer
> type be "int".  It could be char, and I think there's a pretty good
> chance that it will be in this case.

Do you have any empirical backing for that?  It wasn't with
any of the compilers I tried.

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

#156806

On 29/11/2020 09:09, Tim Rentsch wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> 
>> On Monday, November 2, 2020 at 1:01:31 PM UTC-5, Bonita Montero wrote:
>>
>>>> Apparently this works on older compilers:
>>>> enum Boolean{true, false};
>>>> typedef enum Boolean bool;
>>>
>>> enum has the size of an int, which would match the size
>>> of a comparison result.  _Bool and bool usually have the
>>> size of a char.
>>
>> I think you may be thinking of C++, where the underlaying type for
>> enumerated types defaults to 'int'.  However, this is also cross-posted
>>  to comp.lang.c.
>>
>> In C, "An identifier declared as an enumeration constant has type int."
>> (6.4.4.3p2), and "The expression that defines the value of an
>> enumeration constant shall be an integer constant expression that has a
>> value representable as an int."  (6.7.2.2p2).  However, "Each enumerated
>> type shall be compatible with char, a signed integer type, or an
>> unsigned integer type.  The choice of type is implementation-defined
>> ..."  (6.7.2.2p3).  There is no requirement that the compatible integer
>> type be "int".  It could be char, and I think there's a pretty good
>> chance that it will be in this case.
> 
> Do you have any empirical backing for that?  It wasn't with
> any of the compilers I tried.
> 

From the gcc documentation on implementation-defined behaviour:

"""
The integer type compatible with each enumerated type (C90 6.5.2.2, C99
and C11 6.7.2.2).

Normally, the type is unsigned int if there are no negative values in
the enumeration, otherwise int. If -fshort-enums is specified, then if
there are negative values it is the first of signed char, short and int
that can represent all the values, otherwise it is the first of unsigned
char, unsigned short and unsigned int that can represent all the values.

On some targets, -fshort-enums is the default; this is determined by the
ABI.
"""

A quick check with godbolt shows that "-fshort-enums" behaviour is found
on SDCC (for the 8-bit 8051 cpu) and on ARM EABI for embedded ARM
devices.  Some also had it in C++ mode while using full "int" or
"unsigned int" size in C mode.

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

#156380

On 11/2/20 12:38 PM, olcott wrote:
> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> If bool is not a native type in C then they must have changed this at
>>> some point after K&R C. Exactly when was this changed?
>>
>> K&R C never had bool.  The second edition of K&R is essentially the same
>> as the first ANSI and ISO standard, often called C90.
>>
>> _Bool (and stdbool.h) were introduced in C99.
>>
> 
> Apparently this works on older compilers:
> enum Boolean{true, false};
> typedef enum Boolean bool;
> 
> 

Which would REALLY confuse people as this makes 'true' have the value of
0 and thus be false, while 'false' will have the value 1, and thus be true.

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

#156386

On 11/2/2020 12:18 PM, Richard Damon wrote:
> On 11/2/20 12:38 PM, olcott wrote:
>> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> If bool is not a native type in C then they must have changed this at
>>>> some point after K&R C. Exactly when was this changed?
>>>
>>> K&R C never had bool.  The second edition of K&R is essentially the same
>>> as the first ANSI and ISO standard, often called C90.
>>>
>>> _Bool (and stdbool.h) were introduced in C99.
>>>
>>
>> Apparently this works on older compilers:
>> enum Boolean{true, false};
>> typedef enum Boolean bool;
>>
>>
> 
> Which would REALLY confuse people as this makes 'true' have the value of
> 0 and thus be false, while 'false' will have the value 1, and thus be true.
> 

Good catch.

-- 
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#156387

On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote:
> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
...
> > K&R C never had bool. The second edition of K&R is essentially the same 
> > as the first ANSI and ISO standard, often called C90. 
> > 
> > _Bool (and stdbool.h) were introduced in C99. 
> >
> Apparently this works on older compilers: 
> enum Boolean{true, false}; 
> typedef enum Boolean bool;

In addition to the problem with true and false being reversed, there's
an additional problem. _Bool in C (and bool in C++) has a special
properties that cannot be reproduced by simply making bool a typedef
for an ordinary integer type: conversion of a value 'x' of any real or
pointer type to bool type produces the same result as x!=0.

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

#156388

On 11/2/2020 1:18 PM, james...@alumni.caltech.edu wrote:
> On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote:
>> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
> ...
>>> K&R C never had bool. The second edition of K&R is essentially the same
>>> as the first ANSI and ISO standard, often called C90.
>>>
>>> _Bool (and stdbool.h) were introduced in C99.
>>>
>> Apparently this works on older compilers:
>> enum Boolean{true, false};
>> typedef enum Boolean bool;
> 
> In addition to the problem with true and false being reversed, there's
> an additional problem. _Bool in C (and bool in C++) has a special
> properties that cannot be reproduced by simply making bool a typedef
> for an ordinary integer type: conversion of a value 'x' of any real or
> pointer type to bool type produces the same result as x!=0.
> 

enum Boolean{false, true};
typedef enum Boolean bool;


int main()
{
   bool X = 5 > 7;
   bool Y = 7 > 5;

   if (X)
     printf("X is true\n");
   if (!X)
     printf("X is false\n");
   if (Y)
     printf("Y is true\n");
   if (!Y)
     printf("Y is false\n");
}

Output:
X is false
Y is true

-- 
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#156390

On Monday, November 2, 2020 at 2:43:14 PM UTC-5, olcott wrote:
> On 11/2/2020 1:18 PM, james...@alumni.caltech.edu wrote: 
> > On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote: 
> >> On 11/2/2020 11:22 AM, Ben Bacarisse wrote: 
> > ... 
> >>> K&R C never had bool. The second edition of K&R is essentially the same 
> >>> as the first ANSI and ISO standard, often called C90. 
> >>> 
> >>> _Bool (and stdbool.h) were introduced in C99. 
> >>> 
> >> Apparently this works on older compilers: 
> >> enum Boolean{true, false}; 
> >> typedef enum Boolean bool; 
> > 
> > In addition to the problem with true and false being reversed, there's 
> > an additional problem. _Bool in C (and bool in C++) has a special 
> > properties that cannot be reproduced by simply making bool a typedef 
> > for an ordinary integer type: conversion of a value 'x' of any real or 
> > pointer type to bool type produces the same result as x!=0. 
> >
> enum Boolean{false, true}; 
> typedef enum Boolean bool; 
> 
> 
> int main() 
> {
> bool X = 5 > 7;
> bool Y = 7 > 5; 
> 
> if (X) 
> printf("X is true\n"); 
> if (!X) 
> printf("X is false\n"); 
> if (Y) 
> printf("Y is true\n"); 
> if (!Y) 
> printf("Y is false\n"); 
> } 
> 
> Output: 
> X is false 
> Y is true

Try this: printf("(bool)5 is %d\n", (bool)5);

In C99 or greater, with 'bool' defined by <stdbool.h>, the output is
required to be "(boo)5 is 1". As a result, if X has the type bool,
if(X) and if(X==true) have the same meaning.

No typedef for bool as an ordinary integer type can duplicate that
behavior.

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

#156392

On 11/2/2020 2:39 PM, james...@alumni.caltech.edu wrote:
> On Monday, November 2, 2020 at 2:43:14 PM UTC-5, olcott wrote:
>> On 11/2/2020 1:18 PM, james...@alumni.caltech.edu wrote:
>>> On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote:
>>>> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
>>> ...
>>>>> K&R C never had bool. The second edition of K&R is essentially the same
>>>>> as the first ANSI and ISO standard, often called C90.
>>>>>
>>>>> _Bool (and stdbool.h) were introduced in C99.
>>>>>
>>>> Apparently this works on older compilers:
>>>> enum Boolean{true, false};
>>>> typedef enum Boolean bool;
>>>
>>> In addition to the problem with true and false being reversed, there's
>>> an additional problem. _Bool in C (and bool in C++) has a special
>>> properties that cannot be reproduced by simply making bool a typedef
>>> for an ordinary integer type: conversion of a value 'x' of any real or
>>> pointer type to bool type produces the same result as x!=0.
>>>
>> enum Boolean{false, true};
>> typedef enum Boolean bool;
>>
>>
>> int main()
>> {
>> bool X = 5 > 7;
>> bool Y = 7 > 5;
>>
>> if (X)
>> printf("X is true\n");
>> if (!X)
>> printf("X is false\n");
>> if (Y)
>> printf("Y is true\n");
>> if (!Y)
>> printf("Y is false\n");
>> }
>>
>> Output:
>> X is false
>> Y is true
> 
> Try this: printf("(bool)5 is %d\n", (bool)5);
> 
> In C99 or greater, with 'bool' defined by <stdbool.h>, the output is
> required to be "(boo)5 is 1". 

It flunks this test.

> As a result, if X has the type bool,
> if(X) and if(X==true) have the same meaning.

They have the same meaning.

> No typedef for bool as an ordinary integer type can duplicate that
> behavior.
> 

Aren't they supposed to have the same meaning?

-- 
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#156800

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Monday, November 2, 2020 at 2:43:14 PM UTC-5, olcott wrote:
>
>> On 11/2/2020 1:18 PM, james...@alumni.caltech.edu wrote:
>>
>>> On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote:
>>>
>>>> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
>>>
>>> ...
>>>
>>>>> K&R C never had bool.  The second edition of K&R is essentially the same
>>>>> as the first ANSI and ISO standard, often called C90.
>>>>>
>>>>> _Bool (and stdbool.h) were introduced in C99.
>>>>
>>>> Apparently this works on older compilers:
>>>> enum Boolean{true, false};
>>>> typedef enum Boolean bool;
>>>
>>> In addition to the problem with true and false being reversed, there's
>>> an additional problem.  _Bool in C (and bool in C++) has a special
>>> properties that cannot be reproduced by simply making bool a typedef
>>> for an ordinary integer type:  conversion of a value 'x' of any real or
>>> pointer type to bool type produces the same result as x!=0.
>>
>> enum Boolean{false, true};
>> typedef enum Boolean bool;
>>
>>
>> int main()
>> {
>> bool X = 5 > 7;
>> bool Y = 7 > 5;
>>
>> if (X)
>> printf("X is true\n");
>> if (!X)
>> printf("X is false\n");
>> if (Y)
>> printf("Y is true\n");
>> if (!Y)
>> printf("Y is false\n");
>> }
>>
>> Output:
>> X is false
>> Y is true
>
> Try this:  printf("(bool)5 is %d\n", (bool)5);
>
> In C99 or greater, with 'bool' defined by <stdbool.h>, the output is
> required to be "(boo)5 is 1".  As a result, if X has the type bool,
> if(X) and if(X==true) have the same meaning.
>
> No typedef for bool as an ordinary integer type can duplicate that
> behavior.

Is there anything in the C standard that would preclude the
type 'enum Boolean{false, true}' from having a compatible
type of _Bool?  I looked but didn't see anything.

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

#156808

On 29/11/2020 09:14, Tim Rentsch wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> 
>> On Monday, November 2, 2020 at 2:43:14 PM UTC-5, olcott wrote:
>>
>>> On 11/2/2020 1:18 PM, james...@alumni.caltech.edu wrote:
>>>
>>>> On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote:
>>>>
>>>>> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
>>>>
>>>> ...
>>>>
>>>>>> K&R C never had bool.  The second edition of K&R is essentially the same
>>>>>> as the first ANSI and ISO standard, often called C90.
>>>>>>
>>>>>> _Bool (and stdbool.h) were introduced in C99.
>>>>>
>>>>> Apparently this works on older compilers:
>>>>> enum Boolean{true, false};
>>>>> typedef enum Boolean bool;
>>>>
>>>> In addition to the problem with true and false being reversed, there's
>>>> an additional problem.  _Bool in C (and bool in C++) has a special
>>>> properties that cannot be reproduced by simply making bool a typedef
>>>> for an ordinary integer type:  conversion of a value 'x' of any real or
>>>> pointer type to bool type produces the same result as x!=0.
>>>
>>> enum Boolean{false, true};
>>> typedef enum Boolean bool;
>>>
>>>
>>> int main()
>>> {
>>> bool X = 5 > 7;
>>> bool Y = 7 > 5;
>>>
>>> if (X)
>>> printf("X is true\n");
>>> if (!X)
>>> printf("X is false\n");
>>> if (Y)
>>> printf("Y is true\n");
>>> if (!Y)
>>> printf("Y is false\n");
>>> }
>>>
>>> Output:
>>> X is false
>>> Y is true
>>
>> Try this:  printf("(bool)5 is %d\n", (bool)5);
>>
>> In C99 or greater, with 'bool' defined by <stdbool.h>, the output is
>> required to be "(boo)5 is 1".  As a result, if X has the type bool,
>> if(X) and if(X==true) have the same meaning.
>>
>> No typedef for bool as an ordinary integer type can duplicate that
>> behavior.
> 
> Is there anything in the C standard that would preclude the
> type 'enum Boolean{false, true}' from having a compatible
> type of _Bool?  I looked but didn't see anything.
> 

Enumeration types must be compatible to an integer type, and _Bool is
not an integer type.  _Bool cannot be compatible with any integer type,
as it has a rank less than that of any standard integer type.

With that enum, then "(int)((Boolean) 5)" must, I think, evaluate to 5 -
while "(int)((_Bool) 5)" must evaluate to 1.  The enumerated type needs
to be compatible to a char, signed integer type or unsigned integer
type, and I believe that implies it must be able to hold all values of
the corresponding integer type so that conversions back and forth
preserve the value.

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

#156809

David Brown <david.brown@hesbynett.no> writes:

> On 29/11/2020 09:14, Tim Rentsch wrote:
>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
<cut>
>>> No typedef for bool as an ordinary integer type can duplicate that
>>> behavior.
>> 
>> Is there anything in the C standard that would preclude the
>> type 'enum Boolean{false, true}' from having a compatible
>> type of _Bool?  I looked but didn't see anything.
>
> Enumeration types must be compatible to an integer type, and _Bool is
> not an integer type.

Yes it is:

  "The type _Bool and the unsigned integer types that correspond to the
  standard signed integer types are the standard unsigned integer types.
  [...] The standard signed integer types and standard unsigned integer
  types are collectively called the standard integer types..."

> _Bool cannot be compatible with any integer type,
> as it has a rank less than that of any standard integer type.

It is one of the standard integer types.

> With that enum, then "(int)((Boolean) 5)" must [...]

s/Boolean/enum Boolean/

(And I find minimum bracketing simpler: (int)(enum Boolean)5 though I
know that extra parentheses are very popular.)

-- 
Ben.

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

#156811

On 29/11/2020 14:18, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 29/11/2020 09:14, Tim Rentsch wrote:
>>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> <cut>
>>>> No typedef for bool as an ordinary integer type can duplicate that
>>>> behavior.
>>>
>>> Is there anything in the C standard that would preclude the
>>> type 'enum Boolean{false, true}' from having a compatible
>>> type of _Bool?  I looked but didn't see anything.
>>
>> Enumeration types must be compatible to an integer type, and _Bool is
>> not an integer type.
> 
> Yes it is:
> 
>   "The type _Bool and the unsigned integer types that correspond to the
>   standard signed integer types are the standard unsigned integer types.
>   [...] The standard signed integer types and standard unsigned integer
>   types are collectively called the standard integer types..."
> 

You are right - I only looked at the paragraph defining the signed
integer types.  Sorry for the confusion.

>> _Bool cannot be compatible with any integer type,
>> as it has a rank less than that of any standard integer type.
> 
> It is one of the standard integer types.
> 
>> With that enum, then "(int)((Boolean) 5)" must [...]
> 
> s/Boolean/enum Boolean/

I've been doing too much C++ recently...  (And I usually typedef struct,
union and enum types in C.)

> 
> (And I find minimum bracketing simpler: (int)(enum Boolean)5 though I
> know that extra parentheses are very popular.)
> 

I know I used more brackets than necessary - sometimes I like to be more
explicit.  It can help if there are others reading that are not as sure.
 (Mind you, in this case there really isn't scope for misinterpreting
anything.)

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

#156819

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

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 29/11/2020 09:14, Tim Rentsch wrote:
>>
>>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>
> <cut>
>
>>>> No typedef for bool as an ordinary integer type can duplicate that
>>>> behavior.
>>>
>>> Is there anything in the C standard that would preclude the
>>> type 'enum Boolean{false, true}' from having a compatible
>>> type of _Bool?  I looked but didn't see anything.
>>
>> Enumeration types must be compatible to an integer type, and _Bool is
>> not an integer type.
>
> Yes it is:
>
>   "The type _Bool and the unsigned integer types that correspond to the
>   standard signed integer types are the standard unsigned integer types.
>   [...] The standard signed integer types and standard unsigned integer
>   types are collectively called the standard integer types..."

Right.

>> _Bool cannot be compatible with any integer type,
>> as it has a rank less than that of any standard integer type.
>
> It is one of the standard integer types.

Yes.  About _Bool's integer conversion rank, the C standard says
this:

    The rank of _Bool shall be less than the rank of all other
    standard integer types.

The word "other" is indicative that _Bool is a standard integer
type.

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

#156810

On 11/29/20 7:53 AM, David Brown wrote:
> On 29/11/2020 09:14, Tim Rentsch wrote:
>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>>
>>> On Monday, November 2, 2020 at 2:43:14 PM UTC-5, olcott wrote:
>>>
>>>> On 11/2/2020 1:18 PM, james...@alumni.caltech.edu wrote:
>>>>
>>>>> On Monday, November 2, 2020 at 12:39:06 PM UTC-5, olcott wrote:
>>>>>
>>>>>> On 11/2/2020 11:22 AM, Ben Bacarisse wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>> K&R C never had bool.  The second edition of K&R is essentially the same
>>>>>>> as the first ANSI and ISO standard, often called C90.
>>>>>>>
>>>>>>> _Bool (and stdbool.h) were introduced in C99.
>>>>>>
>>>>>> Apparently this works on older compilers:
>>>>>> enum Boolean{true, false};
>>>>>> typedef enum Boolean bool;
>>>>>
>>>>> In addition to the problem with true and false being reversed, there's
>>>>> an additional problem.  _Bool in C (and bool in C++) has a special
>>>>> properties that cannot be reproduced by simply making bool a typedef
>>>>> for an ordinary integer type:  conversion of a value 'x' of any real or
>>>>> pointer type to bool type produces the same result as x!=0.
>>>>
>>>> enum Boolean{false, true};
>>>> typedef enum Boolean bool;
>>>>
>>>>
>>>> int main()
>>>> {
>>>> bool X = 5 > 7;
>>>> bool Y = 7 > 5;
>>>>
>>>> if (X)
>>>> printf("X is true\n");
>>>> if (!X)
>>>> printf("X is false\n");
>>>> if (Y)
>>>> printf("Y is true\n");
>>>> if (!Y)
>>>> printf("Y is false\n");
>>>> }
>>>>
>>>> Output:
>>>> X is false
>>>> Y is true
>>>
>>> Try this:  printf("(bool)5 is %d\n", (bool)5);
>>>
>>> In C99 or greater, with 'bool' defined by <stdbool.h>, the output is
>>> required to be "(boo)5 is 1".  As a result, if X has the type bool,
>>> if(X) and if(X==true) have the same meaning.
>>>
>>> No typedef for bool as an ordinary integer type can duplicate that
>>> behavior.
>>
>> Is there anything in the C standard that would preclude the
>> type 'enum Boolean{false, true}' from having a compatible
>> type of _Bool?  I looked but didn't see anything.
>>
> 
> Enumeration types must be compatible to an integer type, and _Bool is
> not an integer type.  _Bool cannot be compatible with any integer type,
> as it has a rank less than that of any standard integer type.
> 
> With that enum, then "(int)((Boolean) 5)" must, I think, evaluate to 5 -
> while "(int)((_Bool) 5)" must evaluate to 1.  The enumerated type needs
> to be compatible to a char, signed integer type or unsigned integer
> type, and I believe that implies it must be able to hold all values of
> the corresponding integer type so that conversions back and forth
> preserve the value.
> 
> 

Could the implementation define an extended integer type that had sizeof
= sizeof bool, and only 1 value bit and the rest be padding (with a
non-zero value of the padding being a trap representation) and then make
the enum be compatible with that type?

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

#156818

Richard Damon <Richard@Damon-Family.org> writes:

>> On 29/11/2020 09:14, Tim Rentsch wrote:
>>
>>> Is there anything in the C standard that would preclude the
>>> type 'enum Boolean{false, true}' from having a compatible
>>> type of _Bool?  I looked but didn't see anything.
>
> Could the implementation define an extended integer type that had
> sizeof = sizeof bool, and only 1 value bit and the rest be padding
> (with a non-zero value of the padding being a trap representation)
> and then make the enum be compatible with that type?

The compatible type chosen for an enum may be an extended integer
type.

AFAICS an implementation may offer a pair of extended integer
types (one signed, one unsigned) with a width of one and a size
of any integral power of two bytes (which sizeof _Bool certainly
satisfies).  The integer conversion rank of those extended types
would be unusual in that it would be less than the integer
conversion rank of _Bool, but the Standard doesn't preclude that
AFAICT.

Thus it appears that the answer to your question is Yes.

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web