pll: who uses _Bool

[Flash Gordon]

Ian Collins wrote, On 28/10/07 20:07:

Maybe, *might* be used I agree with, I was questioning "in particular
I'd *expect* sizeof (_Bool) to equal sizeof (enum {false, true}) on most
of implementations having _Bool".

I would expect them to be the same size because if it is the most
efficient way to implement one it is the most efficient way to implement
the other. I can also see why they might be different.

 

[Keith Thompson]

Tor Rustad wrote:
CBFalconer wrote:

... snip ...

Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

The macro has nothing to do with type. Wherever the id 'true'
appears, it will be replaced by the id '1'. Similarly for 'false'
and '0'. Any type checking depends entirely on the use of those
ids (0 and 1) in the resultant expression.

``true'' and ``false'' are identifers (I presume that's what you
mean by "id"); ``0'' and ``1'' are not. Yes, I'm nitpicking, but
correct terminology is important.

For example, the expression sequence:

size_t st;
...
st = -true;

whill result in st setting to SIZE_T_MAX, whatever that may be.

Yes, but that's not relevant to the type of ``true''.

``true'' expands to the integer constant ``1'', which is of type
int, regardless of the context in which it appears. (In some
contexts, it may then be implicitly converted to some other type.)

I disagree. I can affect the macro expansion with the '#'
operation. This can change the "1" resulting from the macro
expansion to, say, 1u. No change to the macro is required. The
primary thing that happens is the '1' appears in the code. I can
even envelop that alteration in further ridiculous macros.

The question was:

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

I fail to see how the hypothetical usage of the # operator is relevant
to the question. The types of true, false, and INT_MAX are all the
same: int.

 

[CBFalconer]

.... snip ...

The question was:

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

I fail to see how the hypothetical usage of the # operator is
relevant to the question. The types of true, false, and INT_MAX
are all the same: int.

My point is that we don't have a typed identifier at all. We have
created another representation for the digit 1 (or for 0). Yes,
the unadorned use of such digits can generate an int type constant,
however we are not limited to such unadorned use.

The characters 'true' are simply another glyph for the digit '1'.

 

[Charlie Gordon]

... snip ...

The question was:

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

I fail to see how the hypothetical usage of the # operator is
relevant to the question. The types of true, false, and INT_MAX
are all the same: int.

My point is that we don't have a typed identifier at all. We have
created another representation for the digit 1 (or for 0). Yes,
the unadorned use of such digits can generate an int type constant,
however we are not limited to such unadorned use.

The characters 'true' are simply another glyph for the digit '1'.

Not for the digit 1, for the one-digit token ``1''
Anyway, your point is ridiculous: any identifier can be transmogrified into
something else with macro based token pasting.

int x;
long x1;

Q: what is the type of x?
A: int of course.
CBF: not if I do this: GLUE(x,1) with an appropriate definition of GLUE.

 

[Charlie Gordon]

"Tor Rustad" <[email protected]> a écrit dans le message de (e-mail address removed)... [...]

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

true and false will expand to int constants.

Why this the above *better* under C89, than using

typedef enum {false, true} bool;

consider this:

#if true
...
#endif

The standard explicitly allows this, and mandates that true be defined to
1
for that very purpose (7.16p3). with just the enum, #if true ultimately
evaluates to #if 0. QED

It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.h> in C90. You can write code that reproduces most
of the *useful* semantics, such as:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

Safer this way:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#define false 0
#define true 1
#endif

 

[Keith Thompson]

"Keith Thompson" <[email protected]> a écrit dans le message de
(e-mail address removed)... [...]

It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.h> in C90. You can write code that reproduces most
of the *useful* semantics, such as:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

Safer this way:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#define false 0
#define true 1
#endif

How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

 

[Charlie Gordon]

"Keith Thompson" <[email protected]> a écrit dans le message de (e-mail address removed)... [...]

It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.h> in C90. You can write code that reproduces most
of the *useful* semantics, such as:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

Safer this way:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#define false 0
#define true 1
#endif

How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

They are not much of an effort, and if the case should arise that true is
used in a preprocessor conditional, the bug could be quite difficult to nail
down.

 

[Tor Rustad]

"Keith Thompson" <[email protected]> a écrit dans le message de (e-mail address removed)... [...]
It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.h> in C90. You can write code that reproduces most
of the *useful* semantics, such as:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
Safer this way:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#define false 0
#define true 1
#endif

How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

They are not much of an effort, and if the case should arise that true is
used in a preprocessor conditional, the bug could be quite difficult to nail
down.

I'm siding with Keith here, adding those macros result in more
hard-to-read code, and don't help against a common bug, at least have I
never seen user defined booleans used as pp-token.

IMO, rather using a lint tool, would give a real effect.

 

[Charlie Gordon]

"Keith Thompson" <[email protected]> a écrit dans le message de (e-mail address removed)...
[...]
It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.h> in C90. You can write code that reproduces most
of the *useful* semantics, such as:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
Safer this way:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#define false 0
#define true 1
#endif
How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

They are not much of an effort, and if the case should arise that true is
used in a preprocessor conditional, the bug could be quite difficult to
nail down.

I'm siding with Keith here, adding those macros result in more
hard-to-read code, and don't help against a common bug, at least have I
never seen user defined booleans used as pp-token.

Neither have I, but who bothers to read system and third party header files
shipped with libraries? Why deliberately make these unsuitable for
preprocessor conditionals when c99 explicitly makes them fit for that:

C99 7.16p3:

The remaining three macros are suitable for use in #if preprocessing
directives. They are
true
which expands to the integer constant 1,
false
which expands to the integer constant 0, and
__bool_true_false_are_defined
which expands to the integer constant 1.