bool variable.(a non-standard question)

[shaanxxx]

I have code which says

#define MYBOOL int

This code is very old. people who have written is not avaible. I was
thinking what could be reason.
1) bool datatype was not available that time (10 years back: correct me
if i am wrong)
2) int was word aligned (16bit and 32bit). Writter of above code doesnt
want to give choice to compiler.
if we say bool , compiler can represent this on his way (again,correct
me if i am wrong)
This much i can think of it.

even in many books, i have seen author using int as a flag. example
Richard Stevens, "advance programming in unix environment" . and this
book uses 'restrict' keyword.

Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

Any comment on this will be appreciated.

[goose]

shaanxxx wrote:
<snipped.

Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

Any comment on this will be appreciated.

Don't change it yet; run it first and change it
only if there actually is a performance hit.

--
goose
Have I offended you? Send flames to root@localhost
real email: lelanthran at gmail dot com
website : www.lelanthran.com

[Spiros Bousbouras]

shaanxxx wrote:

I have code which says

#define MYBOOL int

This code is very old. people who have written is not avaible. I was
thinking what could be reason.
1) bool datatype was not available that time (10 years back: correct me
if i am wrong)
2) int was word aligned (16bit and 32bit). Writter of above code doesnt
want to give choice to compiler.
if we say bool , compiler can represent this on his way (again,correct
me if i am wrong)
This much i can think of it.

even in many books, i have seen author using int as a flag. example
Richard Stevens, "advance programming in unix environment" . and this
book uses 'restrict' keyword.

Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

Assuming I got it right then I would have to say that
it's out of topic. Ultimately the answer depends on
the processor you are using and perhaps also the
operating system. Your compiler presumably knows
about these things so read your compiler's documentation
and see if it says anything on how you should declare
variables in order to get the fastest possible access.

[Richard Heathfield]

Spiros Bousbouras said:

<snip>

>
So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

It seems likely. Of course, apart from a bitfield (of type unsigned int and
width 1), there is no C type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

But if space is at a premium, he can decide how many bools he wants:

#define NUM_FLAGS 123 /* or whatever */

Then he can define an array of unsigned char:

#include <limits.h>

unsigned char flag[(NUM_FLAGS + CHAR_BIT - 1) / CHAR_BIT] = {0};

and then use bit-twiddling macros (e.g. see snippets.org) to get at
individual bits.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ben Pfaff]

"shaanxxx" <sh******@yahoo.comwrites:

I have code which says

#define MYBOOL int

[...]

Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

If you are using a modern implementation that has <stdint.h>, I
would suggest using int_fast8_t, which designates the fastest
signed integer type with at least 8 bits.
--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz

[shaanxxx]

Richard Heathfield wrote:

Spiros Bousbouras said:

<snip>

So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

It seems likely. Of course, apart from a bitfield (of type unsigned int and
width 1), there is no C type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

This is also true for 64bit arch ?

[CBFalconer]

shaanxxx wrote:

>
I have code which says

#define MYBOOL int

This code is very old. people who have written is not avaible. I
was thinking what could be reason.
1) bool datatype was not available that time (10 years back:
correct me if i am wrong)
2) int was word aligned (16bit and 32bit). Writter of above code
doesnt want to give choice to compiler.
if we say bool , compiler can represent this on his way (again,
correct me if i am wrong)

C still has no bool type, unless you #include <stdbool.hin C99
systems. After which true and false will be macros that expand to
integers 1 and 0 respectively, and bool will expand to _Bool (which
is system defined, usually as an int).

However, since the dawn of time, C has defined logical expressions
(e.g. (x < y)) as returning either 0 or 1. This is why !!x can be
used to force the value to those, and why we can do arithmetical
tricks with booleans.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Heathfield]

shaanxxx said:

Richard Heathfield wrote:

<snip>

>>
If speed is at a premium, he should choose int:

typedef int bool;

This is also true for 64bit arch ?

It has always been the intent of the powers-that-C that implementors should
choose a size of int that reflects the most natural object size for the
machine, and the most natural size is pretty darned likely also to be the
fastest size.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Spiros Bousbouras]

Richard Heathfield wrote:

Spiros Bousbouras said:

<snip>

So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

It seems likely. Of course, apart from a bitfield (of type unsigned int and
width 1), there is no C type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

>From his opening post I gather that he thinks that

a 64 bit variable may be aligned in such a way as to
allow faster access than int. (I'm assuming that int
is 32 bits on his platform.)

[Richard Heathfield]

Spiros Bousbouras said:

<snip>

>
(I'm assuming that int is 32 bits on his platform.)

Why?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Spiros Bousbouras]

Richard Heathfield wrote:

shaanxxx said:

Richard Heathfield wrote:

<snip>

>
If speed is at a premium, he should choose int:

typedef int bool;

This is also true for 64bit arch ?

It has always been the intent of the powers-that-C that implementors should
choose a size of int that reflects the most natural object size for the
machine, and the most natural size is pretty darned likely also to be the
fastest size.

Does the standard actually say that somewhere ?

[Spiros Bousbouras]

Richard Heathfield wrote:

Spiros Bousbouras said:

<snip>

(I'm assuming that int is 32 bits on his platform.)

Why?

Because he believes that long int might make a
difference in speed so int can't have size 64. Plus
32 bits for int seems a reasonable choice for a 64
bits machine.

[Richard Heathfield]

Spiros Bousbouras said:

Richard Heathfield wrote:

>shaanxxx said:

Richard Heathfield wrote:

<snip>

>>
If speed is at a premium, he should choose int:

typedef int bool;

This is also true for 64bit arch ?

It has always been the intent of the powers-that-C that implementors
should choose a size of int that reflects the most natural object size
for the machine, and the most natural size is pretty darned likely also
to be the fastest size.

Does the standard actually say that somewhere ?

3.1.2.5 has this to say: "A ``plain'' int object has the natural size
suggested by the architecture of the execution environment (large enough to
contain any value in the range INT_MIN to INT_MAX as defined in the header
<limits.h)."

And it's normative text, so yes, this is mandatory for a conforming
implementation.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.eduwrites:

"shaanxxx" <sh******@yahoo.comwrites:

>I have code which says

#define MYBOOL int

[...]

>Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

If you are using a modern implementation that has <stdint.h>, I
would suggest using int_fast8_t, which designates the fastest
signed integer type with at least 8 bits.

<stdint.his new in C99. So is <bool.h>, which would be a better
choice.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

Keith Thompson <ks***@mib.orgwrites:

Ben Pfaff <bl*@cs.stanford.eduwrites:

>"shaanxxx" <sh******@yahoo.comwrites:

>>I have code which says

#define MYBOOL int

[...]

>>Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

If you are using a modern implementation that has <stdint.h>, I
would suggest using int_fast8_t, which designates the fastest
signed integer type with at least 8 bits.

<stdint.his new in C99.

It is new in C99, but many implementations that do not support
all of C99 do include a conforming <stdint.h(e.g. GCC).

So is <bool.h>, which would be a better choice.

There is no standard <bool.h>. You must mean <stdbool.h>. And I
think that bool or _Bool is less likely to optimize strictly for
speed than int_fast8_t.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.eduwrites:

Keith Thompson <ks***@mib.orgwrites:

[...]

><stdint.his new in C99.

It is new in C99, but many implementations that do not support
all of C99 do include a conforming <stdint.h(e.g. GCC).

<OT>Is it supplied by gcc or by the runtime library?</OT>

>So is <bool.h>, which would be a better choice.

There is no standard <bool.h>. You must mean <stdbool.h>. And I
think that bool or _Bool is less likely to optimize strictly for
speed than int_fast8_t.

Yes, thanks for the correction. But I don't see why _Bool *wouldn't*
be implemented as the fastest available type.

For implementations that don't support _Bool (or at least for
portability to such implementations), I suspect that just using int
would be the best choice. Operations on booleans aren't likely to be
a bottleneck, unless you have large arrays of them (and in that case
you might want to use bit vectors to save space).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[ena8t8si]

Spiros Bousbouras wrote:

shaanxxx wrote:

I have code which says

#define MYBOOL int

This code is very old. people who have written is not avaible. I was
thinking what could be reason.
1) bool datatype was not available that time (10 years back: correct me
if i am wrong)
2) int was word aligned (16bit and 32bit). Writter of above code doesnt
want to give choice to compiler.
if we say bool , compiler can represent this on his way (again,correct
me if i am wrong)
This much i can think of it.

even in many books, i have seen author using int as a flag. example
Richard Stevens, "advance programming in unix environment" . and this
book uses 'restrict' keyword.

Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

Assuming I got it right then I would have to say that
it's out of topic.

It's on topic; it's just that the response is
"You have to look somewhere other than the C
language definition to find an answer."

[ena8t8si]

Richard Heathfield wrote:

Spiros Bousbouras said:

<snip>

So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

It seems likely. Of course, apart from a bitfield (of type unsigned int and
width 1), there is no C type that can /only/ take a value from the range
[0, 1], [...]

Yes there is, and that is _Bool. The obsoleted standard
C90 doesn't have such a type.

[ena8t8si]

CBFalconer wrote:

shaanxxx wrote:

I have code which says

#define MYBOOL int

This code is very old. people who have written is not avaible. I
was thinking what could be reason.
1) bool datatype was not available that time (10 years back:
correct me if i am wrong)
2) int was word aligned (16bit and 32bit). Writter of above code
doesnt want to give choice to compiler.
if we say bool , compiler can represent this on his way (again,
correct me if i am wrong)

C still has no bool type, unless you #include <stdbool.hin C99
systems. After which true and false will be macros that expand to
integers 1 and 0 respectively, and bool will expand to _Bool (which
is system defined, usually as an int).

The type _Bool is distinct from int or any other standard
integer type. It may have the same size as int, but it
is a a distinct type.

[Richard Heathfield]

en******@yahoo.com said:

>
Richard Heathfield wrote:

>...apart from a bitfield (of type unsigned int
and width 1), there is no C type that can /only/ take a value from the
range
[0, 1], [...]

Yes there is, and that is _Bool.

Oh, so there is. I forgot to consider parts of the language that are not
widely implemented and therefore not terribly useful. Thanks for the
correction.

The obsoleted standard C90 doesn't have such a type.

It does, however, have a large number of conforming implementations.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[shaanxxx]

Spiros Bousbouras wrote:

Richard Heathfield wrote:

Spiros Bousbouras said:

<snip>

>
So you want to declare a variable which will only
take the values 0 and 1 and you want its type to
be such that access will be as fast as possible , is
that right ?

It seems likely. Of course, apart from a bitfield (of type unsigned int and
width 1), there is no C type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

From his opening post I gather that he thinks that

a 64 bit variable may be aligned in such a way as to
allow faster access than int. (I'm assuming that int
is 32 bits on his platform.)

yes , int is 32 bit on my platform .

[ena8t8si]

Richard Heathfield wrote:

en******@yahoo.com said:

Richard Heathfield wrote:

...apart from a bitfield (of type unsigned int
and width 1), there is no C type that can /only/ take a value from the
range
[0, 1], [...]

Yes there is, and that is _Bool.

Oh, so there is. I forgot to consider parts of the language that are not
widely implemented and therefore not terribly useful. Thanks for the
correction.

The _Bool type is widely available -- now implemented in
compilers that run on a computer near you!

[Richard Heathfield]

en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[ena8t8si]

Richard Heathfield wrote:

en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

[Richard Heathfield]

en******@yahoo.com said:

>
Richard Heathfield wrote:

>en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Richard Heathfield wrote:

en******@yahoo.com said:

>>Richard Heathfield wrote:

>>>en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

add

-std=c99

to your makefiles Heathfield ...

[ena8t8si]

Richard Heathfield wrote:

en******@yahoo.com said:

Richard Heathfield wrote:

en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

Oh, what compiler is that?

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Richard Heathfield wrote:

>en******@yahoo.com said:

>>>Richard Heathfield wrote:

en******@yahoo.com said:

<snip>

>The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

add

-std=c99

to your makefiles Heathfield ...

Assuming Richard uses gcc, the result is a compiler that doesn't
conform to *either* standard. As he has stated here before, he
prefers an implementation (a compiler with a certain set of options)
that conforms to *some* standard; the C89/C90 standard is the only one
available if he uses gcc.

But you knew that.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>>Richard Heathfield wrote:

>>>en******@yahoo.com said:
Richard Heathfield wrote:
>en******@yahoo.com said:
>
><snip>
>
>>The _Bool type is widely available
>
>Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

add

-std=c99

to your makefiles Heathfield ...

Assuming Richard uses gcc, the result is a compiler that doesn't
conform to *either* standard. As he has stated here before, he
prefers an implementation (a compiler with a certain set of options)
that conforms to *some* standard; the C89/C90 standard is the only one
available if he uses gcc.

But you knew that.

Yeah, but then he can't complain that gcc doesn't know about _Bool

Pleeeeze...

[Peter Nilsson]

Richard Heathfield wrote:

... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...

typedef unsigned int bool;

Because you can then do robust boolean bitfields...

struct blah
{
bool flag_1 : 1;
bool flag_2 : 1;
bool flag_3 : 1;
...
};

--
Peter

[Richard Heathfield]

jacob navia said:

Keith Thompson wrote:

>jacob navia <ja***@jacob.remcomp.frwrites:

<snip>

>>
Assuming Richard uses gcc, the result is a compiler that doesn't
conform to *either* standard. As he has stated here before, he
prefers an implementation (a compiler with a certain set of options)
that conforms to *some* standard; the C89/C90 standard is the only one
available if he uses gcc.

But you knew that.

Yeah, but then he can't complain that gcc doesn't know about _Bool

I did no such thing. What I said was that the compiler I use for production
code doesn't know about _Bool. The compiler I use for production code is
gcc ***in conforming mode***, not just unadorned gcc. And in conforming
mode, gcc doesn't know about _Bool.

Indeed, *none* of the compilers I currently have available to me (which
include Microsoft C, Borland C, DJGPP, and Digital Mars C, as well as gcc)
knows about _Bool when invoked in conforming mode.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

en******@yahoo.com said:

>
Richard Heathfield wrote:

>en******@yahoo.com said:

>
Richard Heathfield wrote:
en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

Oh, what compiler is that?

gcc, invoked in conforming mode.

If you're going to suggest turning off conforming mode so that I can get the
compiler to recognise a completely useless data type, forget it - the game
isn't worth the candle.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Peter Nilsson said:

Richard Heathfield wrote:

>... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the
range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...

typedef unsigned int bool;

Because you can then do robust boolean bitfields...

struct blah
{
bool flag_1 : 1;
bool flag_2 : 1;
bool flag_3 : 1;
...
};

If that's your intent, you would probably be better off with an array of
unsigned char and some macros.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[ena8t8si]

Richard Heathfield wrote:

en******@yahoo.com said:

Richard Heathfield wrote:

en******@yahoo.com said:


Richard Heathfield wrote:
en******@yahoo.com said:

<snip>

The _Bool type is widely available

Our definitions of "widely available" clearly differ.

Are you sure of that? When was the last time you looked
into the availability of _Bool, as distinct from the
availability of full C99 compliance?

About two minutes ago. It is not available on the compiler I use for
compiling production code.

Oh, what compiler is that?

gcc, invoked in conforming mode.

If you're going to suggest turning off conforming mode so that I can get the
compiler to recognise a completely useless data type, forget it - the game
isn't worth the candle.

You're a funny guy. :)

I wouldn't presume to tell you which compiler options
to use. However, it does seem fair to say that support
for _Bool is available; just because you choose not
to avail yourself of it doesn't mean it isn't available.

[ena8t8si]

Richard Heathfield wrote:

jacob navia said:

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

<snip>

>
Assuming Richard uses gcc, the result is a compiler that doesn't
conform to *either* standard. As he has stated here before, he
prefers an implementation (a compiler with a certain set of options)
that conforms to *some* standard; the C89/C90 standard is the only one
available if he uses gcc.

But you knew that.

Yeah, but then he can't complain that gcc doesn't know about _Bool

I did no such thing. What I said was that the compiler I use for production
code doesn't know about _Bool. The compiler I use for production code is
gcc ***in conforming mode***, not just unadorned gcc. And in conforming
mode, gcc doesn't know about _Bool.

Indeed, *none* of the compilers I currently have available to me (which
include Microsoft C, Borland C, DJGPP, and Digital Mars C, as well as gcc)
knows about _Bool when invoked in conforming mode.

If you want your comments to be responded to with
respect, you should stop making silly arguments,
which this one is. Of course a C compiler told to
compile C90 doesn't know about _Bool, any more
than Fortran or Pascal compilers do. Just admit
that _Bool is available but you prefer not to use
compilers that don't fully support C99 (or whatever
it is that you do prefer).

[Keith Thompson]

"Peter Nilsson" <ai***@acay.com.auwrites:

Richard Heathfield wrote:

>... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...

typedef unsigned int bool;

Because you can then do robust boolean bitfields...

struct blah
{
bool flag_1 : 1;
bool flag_2 : 1;
bool flag_3 : 1;
...
};

Since C99 uses the name "bool", I wouldn't use that identifier in C90
code. It won't cause any problems for the compiler, since C99
carefully added a new keyword _Bool and declared "bool" only in the
new <stdbool.hheader, but it could still cause confusion for the
reader.

And I'd prefer to use "unsigned int" directly for bit fields:

struct blah {
unsigned flag_1 : 1;
unsigned flag_2 : 1;
unsigned flag_3 : 1;
...
};

since I know that int, signed int, and unsigned int are the only
portably legal types for bit fields in C90.

On the other hand, I suppose a case could be made for using "bool" if
you're trying to be compatible with both C90 and C99.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

en******@yahoo.com said:

>
Richard Heathfield wrote:

>>
If you're going to suggest turning off conforming mode so that I can get
the compiler to recognise a completely useless data type, forget it - the
game isn't worth the candle.

You're a funny guy. :)

I wouldn't presume to tell you which compiler options
to use. However, it does seem fair to say that support
for _Bool is available; just because you choose not
to avail yourself of it doesn't mean it isn't available.

Actually, if it isn't available in my conforming implementation then it
isn't available full stop. But let's go on a flight of fancy and see if
it's available if I invoke my compiler without conformance flags:

me@herecat foo.c
#include <stdio.h>

int main(void)
{
_Bool flag = 0;
printf("%d\n", (int)flag);
return 0;
}

me@heregcc -o foo foo.c
foo.c: In function `main':
foo.c:5: `_Bool' undeclared (first use in this function)
foo.c:5: (Each undeclared identifier is reported only once
foo.c:5: for each function it appears in.)
foo.c:5: parse error before `flag'
foo.c:6: `flag' undeclared (first use in this function)

Apparently not.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

en******@yahoo.com said:

<snip>

Of course a C compiler told to
compile C90 doesn't know about _Bool, any more
than Fortran or Pascal compilers do.

Quite so.

Just admit that _Bool is available

It may well be available, but it is not /widely/ available. For example, it
isn't available in /any/ of the conforming implementations I have readily
to hand.

but you prefer not to use
compilers that don't fully support C99 (or whatever
it is that you do prefer).

I would be delighted to use a compiler that fully supports C99, just as soon
as they become widely available, which hasn't happened yet and isn't likely
to happen for some years, if not decades. In the meantime, since I prefer
to write code that is widely portable, I avoid C99-only features.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Richard Heathfield wrote:

>
I would be delighted to use a compiler that fully supports C99, just as soon
as they become widely available, which hasn't happened yet and isn't likely
to happen for some years, if not decades. In the meantime, since I prefer
to write code that is widely portable, I avoid C99-only features.

Yes. This is YOUR choice. And there are many people programming
for MSDOS, or for the ATARI emulator.

Who cares?

[jacob navia]

Richard Heathfield wrote:

en******@yahoo.com said:

>>Richard Heathfield wrote:

>>>If you're going to suggest turning off conforming mode so that I can get
the compiler to recognise a completely useless data type, forget it - the
game isn't worth the candle.

You're a funny guy. :)

I wouldn't presume to tell you which compiler options
to use. However, it does seem fair to say that support
for _Bool is available; just because you choose not
to avail yourself of it doesn't mean it isn't available.

Actually, if it isn't available in my conforming implementation then it
isn't available full stop. But let's go on a flight of fancy and see if
it's available if I invoke my compiler without conformance flags:

me@herecat foo.c
#include <stdio.h>

int main(void)
{
_Bool flag = 0;
printf("%d\n", (int)flag);
return 0;
}

me@heregcc -o foo foo.c
foo.c: In function `main':
foo.c:5: `_Bool' undeclared (first use in this function)
foo.c:5: (Each undeclared identifier is reported only once
foo.c:5: for each function it appears in.)
foo.c:5: parse error before `flag'
foo.c:6: `flag' undeclared (first use in this function)

Apparently not.

Yes. The fact that (as I told you) you should use
-std=c99
is too much for you to understand apparently

Who cares?

If you do not want to use _Bool, go ahead, avoid it. It is your personal
choice and you ar entitled to your opinion.

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>>
I would be delighted to use a compiler that fully supports C99, just as
soon as they become widely available, which hasn't happened yet and isn't
likely to happen for some years, if not decades. In the meantime, since I
prefer to write code that is widely portable, I avoid C99-only features.

Yes. This is YOUR choice.

No doubt you prefer to write code that is nailed not only to a particular
platform but even to a particular compiler. And that's fine, if it meets
your needs. But it doesn't meet everybody's needs.

And there are many people programming
for MSDOS, or for the ATARI emulator.

And for mainframes, minicomputers, embedded systems, and so on.

Who cares?

Not you, obviously, but lots of other people care. Especially those - such
as myself - who need to write C code that works on mainframes,
minicomputers, embedded systems, and so on.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

<snip>

>Actually, if it isn't available in my conforming implementation then it
isn't available full stop. But let's go on a flight of fancy and see if
it's available if I invoke my compiler without conformance flags:

<snip>

>>
me@heregcc -o foo foo.c
foo.c: In function `main':
foo.c:5: `_Bool' undeclared (first use in this function)
foo.c:5: (Each undeclared identifier is reported only once
foo.c:5: for each function it appears in.)
foo.c:5: parse error before `flag'
foo.c:6: `flag' undeclared (first use in this function)

Apparently not.

Yes. The fact that (as I told you) you should use
-std=c99
is too much for you to understand apparently

If you didn't keep suggesting I'm stupid every time you failed to understand
me, I might have a higher opinion of you.

me@heregcc -std=c99 -o foo foo.c
cc1: unknown C standard `c99'
foo.c: In function `main':
foo.c:5: `_Bool' undeclared (first use in this function)
foo.c:5: (Each undeclared identifier is reported only once
foo.c:5: for each function it appears in.)
foo.c:5: parse error before `flag'
foo.c:6: `flag' undeclared (first use in this function)

So - it's still not available, even if I use this non-existent compiler flag
you keep going on about.

The point is this: that _Bool is /not/ widely available. It is indeed
available on /some/ implementations, and some of those to whom it /is/
available think that is sufficient to mean it can be used in portable code.
"It works on my system, and therefore I presume it works everywhere." I
have little patience for such a short-sighted attitude.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[goose]

Peter Nilsson wrote:

Richard Heathfield wrote:

>>... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...

typedef unsigned int bool;

Because you can then do robust boolean bitfields...

struct blah
{
bool flag_1 : 1;
bool flag_2 : 1;
bool flag_3 : 1;
...
};

It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".

--
goose
Have I offended you? Send flames to root@localhost
real email: lelanthran at gmail dot com
website : www.lelanthran.com

[Keith Thompson]

goose <lk************@webmail.co.zawrites:

Peter Nilsson wrote:

>Richard Heathfield wrote:

>>>... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...
typedef unsigned int bool;
Because you can then do robust boolean bitfields...
struct blah
{
bool flag_1 : 1;
bool flag_2 : 1; bool flag_3 : 1;
...
};

It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".

Why doesn't it make sense? In C99, bit fields of type _Bool are legal
(and limited to a width of 1 bit). It seems perfectly sensible to me.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[goose]

Keith Thompson wrote:

goose <lk************@webmail.co.zawrites:

>>Peter Nilsson wrote:

>>>Richard Heathfield wrote:
... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...
typedef unsigned int bool;
Because you can then do robust boolean bitfields...
struct blah
{
bool flag_1 : 1;
bool flag_2 : 1; bool flag_3 : 1;
...
};

It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".

Why doesn't it make sense? In C99, bit fields of type _Bool are legal
(and limited to a width of 1 bit). It seems perfectly sensible to me.

Let me try again:
It doesn't make sense for a boolean type to have
more than a single bitfield of length 1.
--
goose
Have I offended you? Send flames to root@localhost
real email: lelanthran at gmail dot com
website : www.lelanthran.com

[Keith Thompson]

goose <lk************@webmail.co.zawrites:

Keith Thompson wrote:

>goose <lk************@webmail.co.zawrites:

>>>Peter Nilsson wrote:

Richard Heathfield wrote:
>... Of course, apart from a bitfield (of type unsigned int and
>width 1), there is no [C90] type that can /only/ take a value
>from the range [0, 1], and a bitfield would be unlikely to win
>any awards for speed.
>
>If speed is at a premium, he should choose int:
>
>typedef int bool;

I prefer...
typedef unsigned int bool;
Because you can then do robust boolean bitfields...
struct blah
{
bool flag_1 : 1;
bool flag_2 : 1; bool flag_3 : 1;
...
};
It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".

Why doesn't it make sense? In C99, bit fields of type _Bool are
legal
(and limited to a width of 1 bit). It seems perfectly sensible to me.

Let me try again:
It doesn't make sense for a boolean type to have
more than a single bitfield of length 1.

I'm afraid I don't know what you're talking about.

Only a structure type (or a union?) can have bitfields. A structure
can have bitfields *of* a boolean type, but it makes no sense for a
boolean type to have bitfields -- and I don't see than anybody
suggested otherwise. ("struct blah" above is not a boolean type.)

Can you re-phrase your point?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Old Wolf]

Richard Heathfield wrote:

I did no such thing. What I said was that the compiler I use for production
code doesn't know about _Bool. The compiler I use for production code is
gcc ***in conforming mode***, not just unadorned gcc. And in conforming
mode, gcc doesn't know about _Bool.

Invoked with the switch -std=c99, gcc is in conforming mode --
conforming to C99.

(Please don't give me that rubbish about it not actually conforming
to C99. IMHO, conformance doesn't have to be 100% in order to
say that it conforms. I have a C89 compiler that doesn't
zero-initialize uninitialized static data. Does that mean that my
compiler is worthless? It seems an irrelevant semantic quibble to say
that this compiler doesn't conform to C89 because of that -- and
especially bad to say that the compiler is worthless and not
suitable for use with portable code.)

[Old Wolf]

Richard Heathfield wrote:

>
If you're going to suggest turning off conforming mode so that I can get the
compiler to recognise a completely useless data type, forget it - the game
isn't worth the candle.

Well, what other data type allows you to write:

Type foo()
{
return (expression);
}

and have the returned value compare equal to 0 iff (expression)
does, for all possible integral types of (expression) ?

The only one is the largest unsigned integral type supported
on that machine. If you go for "unsigned long" then your code
won't be portable to C99 (not that you'd care, I imagine), and
at any rate, using unsigned long when a shorter type would do
can cause considerable overhead (eg. on a CPU that only
has 16-bit registers).

If you don't see the value of having a true boolean type, then
that's fine -- but other people do see the value.

[Ben Pfaff]

"Old Wolf" <ol*****@inspire.net.nzwrites:

(Please don't give me that rubbish about it not actually conforming
to C99. IMHO, conformance doesn't have to be 100% in order to
say that it conforms. I have a C89 compiler that doesn't
zero-initialize uninitialized static data. Does that mean that my
compiler is worthless?

No. It's a different question whether a compiler is useful or
whether it conforms to a language standard.

It seems an irrelevant semantic quibble to say that this
compiler doesn't conform to C89 because of that -- and
especially bad to say that the compiler is worthless and not
suitable for use with portable code.)

Of course it doesn't conform to C89 because of that. That
doesn't mean it's worthless, by any means--it just means that it
won't correctly work with all strictly conforming programs.
--
"If I've told you once, I've told you LLONG_MAX times not to
exaggerate."
--Jack Klein

[Richard Heathfield]

Old Wolf said:

Richard Heathfield wrote:

>I did no such thing. What I said was that the compiler I use for
production code doesn't know about _Bool. The compiler I use for
production code is gcc ***in conforming mode***, not just unadorned gcc.
And in conforming mode, gcc doesn't know about _Bool.

Invoked with the switch -std=c99,

The version of gcc I use doesn't recognise the -std=c99 flag.

gcc is in conforming mode -- conforming to C99.

Not so. See http://gcc.gnu.org/c99status.html

(Please don't give me that rubbish about it not actually conforming
to C99. IMHO, conformance doesn't have to be 100% in order to
say that it conforms.

That isn't what the Standard says. Conformance is not a matter of opinion.
Its meaning is laid out in the Standard.

I have a C89 compiler that doesn't
zero-initialize uninitialized static data. Does that mean that my
compiler is worthless?

No, but it does mean that it doesn't conform to the C89 Standard, so your
claim that it is a "C89 compiler" is incorrect. It also means it's not very
useful for compiling programs that rely on C's guarantee that static data
is default-initialised where no explicit initialisation is provided within
the program code itself.

It seems an irrelevant semantic quibble to say
that this compiler doesn't conform to C89 because of that -- and
especially bad to say that the compiler is worthless

I have never claimed that.

and not suitable for use with portable code.)

If the compiler doesn't conform to the Standard, then whether it is suitable
for compiling portable code depends heavily on /how/ it doesn't conform,
and whether that non-conformance affects its ability correctly to translate
the program. In the case you cite, the compiler that doesn't correctly
initialise static data will compile quite a large body of C code
incorrectly.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)