Where is the best place to define TRUE and FALSE?
Are they in any of the standard include files, ever?
Do any standards apply?
What I've traditionally done is something like:
#ifndef (TRUE)
#define TRUE (1)
#endif
(and same for FALSE).
But is there a "standard place" or a standard way of thinking about these?
------------------------------------------------------------
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
Jan 14 '07
71  33091 
Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
> #if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
bool is supposed to be a macro, too.
> #define not !
#define and &&
#define or ||
#define xor ^
#endif
Not under C90. The point of the typedef is that the usage will be
similar to the C99 usage, i.e.:
bool a, b, c;
will make all three items bools. This won't happen if bool is a
macro for int.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Yevgen Muntyan wrote:
CBFalconer wrote:
.... snip ...
>>
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
Which is just what you want. If the compiler is C99 stdbool and
iso946 will be included, else the substitute definitions appear.
You should get the same net results using either ansi, C90, or
C99. This is a header file, stdops.h. Put it where you will and
#include it in your source.
>
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Yevgen Muntyan <mu****************@tamu.eduwrites:
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
[...]
Or just include <stdbool.h>, which will work too ;)
Only if it exists, and only if the compiler (in its current mode)
recognizes the _Bool keyword.
You sure need stdbool.h to exist to include it, but why would you need
_Bool?
Because <stdbool.hcontains (the equivalent of)
#define bool _Bool
Though an implementation could either provide a <stdbool.hthat also
compiles in C90 mode, or can recognize _Bool in C90 mode (it's in the
implementation namespace).
--
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.
CBFalconer <cb********@yahoo.comwrites:
Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
bool is supposed to be a macro, too.
#define not !
#define and &&
#define or ||
#define xor ^
#endif
Not under C90. The point of the typedef is that the usage will be
similar to the C99 usage, i.e.:
bool a, b, c;
will make all three items bools. This won't happen if bool is a
macro for int.
This:
typedef int bool;
bool a, b, c;
and this:
#define bool int
bool a, b, c;
are equivalent (except that one creates a macro and the other
doesn't). A typedef does *not* create a new type; it only creates an
alias for an existing type. In both cases above, a, b, and c are of
type int.
--
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.
CBFalconer wrote:
Yevgen Muntyan wrote:
>CBFalconer wrote:
... snip ...
>>See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
Which is just what you want. If the compiler is C99 stdbool and
iso946 will be included, else the substitute definitions appear.
You should get the same net results using either ansi, C90, or
C99. This is a header file, stdops.h. Put it where you will and
#include it in your source.
And include some other header which includes stdbool.h
and get an error. It's not what I want for sure.
Note, this "other header" thing is real, e.g. curses.h and ncurses.h
include <stdbool.hon linux and freebsd machines here.
Regards,
Yevgen
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>Keith Thompson wrote:
>>Yevgen Muntyan <mu****************@tamu.eduwrites:
[...]
>>>Or just include <stdbool.h>, which will work too ;)
Only if it exists, and only if the compiler (in its current mode)
recognizes the _Bool keyword.
You sure need stdbool.h to exist to include it, but why would you need
_Bool?
Because <stdbool.hcontains (the equivalent of)
#define bool _Bool
Though an implementation could either provide a <stdbool.hthat also
compiles in C90 mode, or can recognize _Bool in C90 mode (it's in the
implementation namespace).
Funny. You also need stdbool.h not to contain lines equivalent to
#undef frobnicate
frobnicate(frob frob)
because they would produce compilation errors. Yes, when I said
"just include <stdbool.h>", I meant the case when it exists *and*
works; I didn't mean "include <stdbool.hand tell your compiler
to error when using it". Sorry for being so not precise, and note
the smiley there and here :)
Regards,
Yevgen
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>CBFalconer wrote:
>>Yevgen Muntyan wrote:
... snip ...
The following code doesn't compile with "gcc foo.c":
#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
--------------------------------------------------
#include <stdbool.h>
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
int main (void)
{
}
Right. If you add an unconditional "#include <stdbool.h>" to code
that carefully tests whether C99 is supported, it will break if
compiled in non-C99 mode. So don't do that.
It's like that joke about a doctor, isn't it? Don't do what, use any
third-party headers? Or don't use gcc without -std=c99 switch? Or
do use this "careful" code, and then let poor innocent user think
why his "./configure; make; make install" doesn't work. Of course,
on his evil system foo.h includes goo.h which includes ncurses.h
because libgoo author did it for some reason, what a bad luck for
user.
Yevgen
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>Ben Pfaff wrote:
>>CBFalconer <cb********@yahoo.comwrites:
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
bool is supposed to be a macro, too.
#define not !
#define and &&
#define or ||
#define xor ^
#endif
Not under C90. The point of the typedef is that the usage will be
similar to the C99 usage, i.e.:
bool a, b, c;
will make all three items bools. This won't happen if bool is a
macro for int.
This:
typedef int bool;
bool a, b, c;
and this:
#define bool int
bool a, b, c;
are equivalent (except that one creates a macro and the other
doesn't). A typedef does *not* create a new type; it only creates
an alias for an existing type. In both cases above, a, b, and c
are of type int.
You're right, I was wrong. I think my original reason for the
typedef was that was what existed in the N869 standard, but that
seems to be an alternate universe. A define is fine. Does it
really matter?
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Yevgen Muntyan wrote:
>
CBFalconer wrote:
Yevgen Muntyan wrote:
CBFalconer wrote:
... snip ...
>See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
Which is just what you want. If the compiler is C99 stdbool and
iso946 will be included, else the substitute definitions appear.
You should get the same net results using either ansi, C90, or
C99. This is a header file, stdops.h. Put it where you will and
#include it in your source.
And include some other header which includes stdbool.h
and get an error. It's not what I want for sure.
Note, this "other header" thing is real, e.g. curses.h and ncurses.h
include <stdbool.hon linux and freebsd machines here.
So what? All system headers can be included multiple times. If
it's not C99 the header doesn't exist. If curses/ncurses.h include
stdbool under C90 they are WRONG.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
CBFalconer wrote:
Yevgen Muntyan wrote:
CBFalconer wrote:
Yevgen Muntyan wrote:
>CBFalconer wrote:
>>
... snip ...
>>See the stdops.h header below. You should also test for __STDC__.
>>Use -W -Wall -ansi -pedantic with gcc.
>[snip]
>>
>It (namely the code below) suffers from the very same problem.
>__STDC_VERSION__ gets defined only if you use -std=c99, when it's
>pointless. -ansi doesn't make it work.
>
Which is just what you want. If the compiler is C99 stdbool and
iso946 will be included, else the substitute definitions appear.
You should get the same net results using either ansi, C90, or
C99. This is a header file, stdops.h. Put it where you will and
#include it in your source.
And include some other header which includes stdbool.h
and get an error. It's not what I want for sure.
Note, this "other header" thing is real, e.g. curses.h and ncurses.h
include <stdbool.hon linux and freebsd machines here.
So what? All system headers can be included multiple times. If
it's not C99 the header doesn't exist. If curses/ncurses.h include
stdbool under C90 they are WRONG.
C90 implementations are allowed to provide stdbool.h as an extension,
and platform-specific libraries may legitimately contain non-portable
code. ncurses is not wrong to include stdbool.h even in C90 mode.
Harald van D??k <tr*****@gmail.comwrote:
C90 implementations are allowed to provide stdbool.h as an extension,
and platform-specific libraries may legitimately contain non-portable
code. ncurses is not wrong to include stdbool.h even in C90 mode.
ncurses includes stdbool.h if it is (by default) configured to support
C++ as well as C. X/Open states that curses.h defines TRUE and FALSE.
C++ has its own flavor. To make them work together (as well as have
the same binary interface), it includes headers and/or defines symbols
as needed.
(this is not intended to argue with the purists in this thread who
aren't concerned with actually writing code ;-)
--
Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
On Mon, 15 Jan 2007 10:17:32 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
>jacob navia said:
>Richard Heathfield a écrit :
<snip>
>>Neither C90 nor C99 defines TRUE. I didn't actually check for
FALSE, but I'm 99.9% certain it doesn't appear within the text of the
Standard.
This is wrong advice
Chapter and verse, please, Mr Navia. (Translation: you're wrong.)
He is, but you could perhaps have been a little more informative. I
knew what you meant, but newbies might not have realised the
significance without a clue or two.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mark McIntyre said:
On Mon, 15 Jan 2007 10:17:32 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
>>jacob navia said:
>>Richard Heathfield a écrit :
<snip>
>>>Neither C90 nor C99 defines TRUE. I didn't actually check for
FALSE, but I'm 99.9% certain it doesn't appear within the text of the
Standard.
This is wrong advice
Chapter and verse, please, Mr Navia. (Translation: you're wrong.)
He is, but you could perhaps have been a little more informative.
Yes. I like to give people a chance to work it out for themselves if
possible. Alas, they rarely do. But *when* they do, it's worth it just to
see the look on their faces...
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield <rj*@see.sig.invalidwrites:
Yes. I like to give people a chance to work it out for themselves if
possible. Alas, they rarely do. But *when* they do, it's worth it just to
see the look on their faces...
Do you get a video feed for comp.lang.c, then? I haven't heard
about that feature.
--
"I should killfile you where you stand, worthless human." --Kaz
Ben Pfaff said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Yes. I like to give people a chance to work it out for themselves if
possible. Alas, they rarely do. But *when* they do, it's worth it just to
see the look on their faces...
Do you get a video feed for comp.lang.c, then? I haven't heard
about that feature.
TINC.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Thomas Dickey <di****@saltmine.radix.netwrote:
ncurses includes stdbool.h if it is (by default) configured to support
C++ as well as C. X/Open states that curses.h defines TRUE and FALSE.
C++ has its own flavor. To make them work together (as well as have
^ (of "bool" - both in X/Open curses and C++)
--
Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
CBFalconer wrote:
Richard Heathfield wrote:
>CBFalconer said:
>>Richard Heathfield wrote:
<snip>
>>>Neither C90 nor C99 defines TRUE. I didn't actually check
for FALSE, but I'm 99.9% certain it doesn't appear within the
text of the Standard.
The operative verbiage, from N869, is:
...irrelevant, since it mentions neither TRUE nor FALSE.
The point is that C99 has standardized those names in lower case,
so I advise jumping on the bandwagon and conforming to that. A
slight babel reduction.
It's blasphemy, I tell you!!!
How about if I use:
#include "stdbool.h"
#define TRUE true
#define FALSE false
;-)
(ISTM that the only decent thing for C99 to have done...
would be to standardize on *both* upper and lower case
for these. After all, what are you going to do with
TRUE *besides* use it to mean true???)
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
"Keith Thompson" <ks***@mib.orgwrote in message
Yevgen Muntyan <mu****************@tamu.eduwrites:
>CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
The following code doesn't compile with "gcc foo.c":
#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
--------------------------------------------------
#include <stdbool.h>
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
int main (void)
{
}
Right. If you add an unconditional "#include <stdbool.h>" to code
that carefully tests whether C99 is supported, it will break if
compiled in non-C99 mode. So don't do that.
The whole point of defining "true" and "false" is to make code easier to
read.
However we are treated to lines of complex conditional includes which need
even more tweaking if certain system characteristics are not met.
bool breaks libraries.
"Malcolm McLean" <re*******@btinternet.comwrote in message
news:gZ******************************@bt.com...
>
"Keith Thompson" <ks***@mib.orgwrote in message
>Yevgen Muntyan <mu****************@tamu.eduwrites:
>>CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
The following code doesn't compile with "gcc foo.c":
#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
--------------------------------------------------
#include <stdbool.h>
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
int main (void)
{
}
Right. If you add an unconditional "#include <stdbool.h>" to code
that carefully tests whether C99 is supported, it will break if
compiled in non-C99 mode. So don't do that.
The whole point of defining "true" and "false" is to make code easier to
read.
However we are treated to lines of complex conditional includes which need
even more tweaking if certain system characteristics are not met.
bool breaks libraries.
That's what Keith said: that the people who matter went for a macro that
makes _Bool the keyword, unless I misunderstand. I am certain that these
people realize that they can't make changes in the standard without breaking
_some library. LS
Keith Thompson <ks***@mib.orgwrites:
Yevgen Muntyan <mu****************@tamu.eduwrites:
CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
>The following code doesn't compile with "gcc foo.c":
>>
>#include <stdbool.h>
>#if __STDC_VERSION__ >= 199901L
>#include <stdbool.h>
>#else
>typedef enum { false, true } bool;
>#endif
>int main (void)
>{
> return 0;
>}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
--------------------------------------------------
#include <stdbool.h>
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
int main (void)
{
}
Right. If you add an unconditional "#include <stdbool.h>" to code
that carefully tests whether C99 is supported, it will break if
compiled in non-C99 mode. So don't do that.
I think there's a real potential problem here that I haven't been
taking seriously enough.
The fact is, C99 conformance is not (currently) an all-or-nothing
thing. A number of implementations support some, but not all, C99
features. In particular, an implementation can support <stdbool.h>,
and possibly the _Bool keyword, without setting __STDC_VERSION__ to
indicate C99 conformance. This is probably even a reasonable thing to
do while working on full conformance.
For code written to work under such an implementation, it's likely
that some separately developed part of the program, such as a library
header will have a "#include <stdbool.h>" header. Since <stdbool.h>
defines false, true, and bool as macros, this can conflict with code
that attempts to define the same identifiers.
I think that adding #undef directives before attempting to define
these identifiers should fix at least part of the problem. Defining
them in a way as close to what <stdbool.hdoes as possible is
probably also a good idea.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
#undef false
#undef true
#undef bool
#define false 0
#define true 1
#define bool int
#endif
All this can be put into a header file, say "mystdbool.h".
There *could* still be problems if the third-party code that uses
<stdbool.hdepends on attributes of _Bool (or bool) that don't apply
to int, such as the fact that converting any non-zero value to bool
yields 1.
--
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.
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
Keith Thompson <ks***@mib.orgwrites:
>Yevgen Muntyan <mu****************@tamu.eduwrites:
CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
The following code doesn't compile with "gcc foo.c":
#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]
It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.
--------------------------------------------------
#include <stdbool.h>
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
int main (void)
{
}
Right. If you add an unconditional "#include <stdbool.h>" to code
that carefully tests whether C99 is supported, it will break if
compiled in non-C99 mode. So don't do that.
I think there's a real potential problem here that I haven't been
taking seriously enough.
The fact is, C99 conformance is not (currently) an all-or-nothing
thing. A number of implementations support some, but not all, C99
features. In particular, an implementation can support <stdbool.h>,
and possibly the _Bool keyword, without setting __STDC_VERSION__ to
indicate C99 conformance. This is probably even a reasonable thing to
do while working on full conformance.
For code written to work under such an implementation, it's likely
that some separately developed part of the program, such as a library
header will have a "#include <stdbool.h>" header. Since <stdbool.h>
defines false, true, and bool as macros, this can conflict with code
that attempts to define the same identifiers.
I think that adding #undef directives before attempting to define
these identifiers should fix at least part of the problem. Defining
them in a way as close to what <stdbool.hdoes as possible is
probably also a good idea.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
#undef false
#undef true
#undef bool
#define false 0
#define true 1
#define bool int
#endif
All this can be put into a header file, say "mystdbool.h".
There *could* still be problems if the third-party code that uses
<stdbool.hdepends on attributes of _Bool (or bool) that don't apply
to int, such as the fact that converting any non-zero value to bool
yields 1.
I would ask, at least rhetorically, how would you characterize a library
that fails in the face of the above preproceesor directives? Me, I would
call it junk. LS
"Lane Straatman" <in*****@invalid.netwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
[...]
I think that adding #undef directives before attempting to define
these identifiers should fix at least part of the problem. Defining
them in a way as close to what <stdbool.hdoes as possible is
probably also a good idea.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
#undef false
#undef true
#undef bool
#define false 0
#define true 1
#define bool int
#endif
All this can be put into a header file, say "mystdbool.h".
There *could* still be problems if the third-party code that uses
<stdbool.hdepends on attributes of _Bool (or bool) that don't apply
to int, such as the fact that converting any non-zero value to bool
yields 1.
I would ask, at least rhetorically, how would you characterize a library
that fails in the face of the above preproceesor directives? Me, I would
call it junk. LS
Not necessarily.
Assume the implementation provides a <stdbool.hheader that fully
conforms to C99, but the implementation as a whole does not. The
compiler supports the _Bool keyword (as an extension), and <stdbool.h>
has "#define bool _Bool".
One of your source files has the following:
....
#include "mystdbool.h"
#include "thirdpartylibrary.h"
....
and thirdpartylibrary.h has
#include <stdbool.h>
Then the "#define bool _Bool" in <stdbool.his a constraint
violation, because "bool" is already #defined as int.
The implementation could avoid the problem by #undef'ing false, true,
and bool in <stdbool.h>, but it's not required to do so.
It would be nice, I think, if it were possible to make a #include
directive conditional on whether the header exists. For example:
#if header_exists <stdbool.h>
#include <stdbool.h>
#else
#undef false
#undef true
#undef bool
#define false 0
#define true 1
#define bool int
#endif
Although typical real-world software does this by doing tests at build
time and generating source code based on the results (GNU autoconf is
an example). It's outside the scope of the C language, and it's not
necessarily entirely portable, but it's more flexible.
--
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. This thread has been closed and replies have been disabled. Please start a new discussion. |
