Where is stdbool.h?

Question

I want to find the _Bool definition on my system, so for systems where it's missing I can implement it. I've seen various definitions for it here and on other sites, but wanted to check on the system for the definitive definition.

Slight problem, in that I can't find where _Bool is defined or even stdbool.h

mussys@debmus:~$ find /usr/include/* -name stdbool.h
/usr/include/c++/4.3/tr1/stdbool.h

And grep for _Bool on /usr/include/* and /usr/include/*/* does not find it either.

So where is it?

Solution 1

_Bool is a built-in type, so don't expect to find a definition for it in a header file, even a system header file.

Having said that, guessing your system from the paths that you are searching, have you looked in /usr/lib/gcc/*/*/include ?

My "real" stdbool.h lives there. As expected it #defines bool to be _Bool. As _Bool is a type native to the compiler there's no definition for it in the header file.

Solution 2

As a note:

The _Bool is defined in C99. If you build your program with:

gcc -std=c99

You can expect it to be there.

Solution 3

Other people have replied to the question on _Bool location and finding if C99 is declared... however, I am not satisfied with the self-made declaration everyone gave.

Why won't you completely define the type?

typedef enum { false, true } bool;

Solution 4

_Bool is a predefined type in C99, much like int or double. You will not find the definition for int in any header file either.

What you can do is

• check the compiler is C99
• if it is use _Bool
• otherwise use some other type (int or unsigned char)

For example:

#if defined __STDC__ && defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
/* have a C99 compiler */
typedef _Bool boolean;
#else
/* do not have a C99 compiler */
typedef unsigned char boolean;
#endif

Solution 5

some compilers don't offer _Bool keywords, so I wrote my own stdbool.h :

#ifndef STDBOOL_H_
#define STDBOOL_H_

/**
 * stdbool.h
 * Author    - Yaping Xin
 * E-mail    - xinyp at live dot com
 * Date      - February 10, 2014
 * Copyright - You are free to use for any purpose except illegal acts
 * Warrenty  - None: don't blame me if it breaks something
 *
 * In ISO C99, stdbool.h is a standard header and _Bool is a keyword, but
 * some compilers don't offer these yet. This header file is an 
 * implementation of the stdbool.h header file.
 *
 */

#ifndef _Bool
typedef unsigned char _Bool;
#endif /* _Bool */

/**
 * Define the Boolean macros only if they are not already defined.
 */
#ifndef __bool_true_false_are_defined
#define bool _Bool
#define false 0 
#define true 1
#define __bool_true_false_are_defined 1
#endif /* __bool_true_false_are_defined */

#endif /* STDBOOL_H_ */

View more solutions

Comments

[James Morris]

Thanks. No hadn't checked there, but my system is the same yes.

[James Morris]

$ echo '_Bool a;' | gcc -std=c99 -x c -c - ... $ echo $? ... 0 ... I see.

[James Morris]

Thanks, but this is not what I was asking.

[pbos]

I'd think that no such functionality definable in a c header. All types that exist wrap, and if you'd compare a (unsigned char) bool (= 2) with another bool(=3), they wouldn't match. So true != true, and that'd suck. Also bool b1 == true might also fail. As no datatypes (except \Bool) have this behaviour, you probably can't make one yourself, since it requires compiler backend support, and you cannot overload operators. You could do cmp_bool(bool b, bool b2), but that's probably really not what you wanted. I can't guarantee that I'm right, but I hope that added something atleast. :)

[pbos]

That's "underscore Bool", formatting got fscked up, and backslash underscore didn't help.

[James Morris]

I'm using autotools which tells me about _Bool via HAVE__BOOL and HAVE_STD_BOOL_H but this way looks like a fair alternative.

[James Morris]

I see what you're saying, but why would I set a bool to 2 or 3? See bottom of the page I found while googling "enum bool c" lysator.liu.se/c/c-faq/c-8.html

[James Morris]

I think it's overkill after I decided to google "bool enum c" which sent me to lysator.liu.se/c/c-faq/c-8.html - see bottom of page regarding the danger of #defining true to be 1·

[Adrien Plisson]

i do agree with the arguments provided in your link. personally, i define true and false for clarity when assigning to a boolean variable. coming from a strongly-typed background, for me, a bool is not a char nor an int, it is a type by itself, thus the enum definition above. also, i do think that automatic conversion from int to bool is not quite a good idea (and this applies to any automatic conversion).

[pbos]

This would happen if you wanted to add boolean values (could be used, not required in any way). But if you wanted to typecast an int to a bool this could be an issue. (bool b = (bool)int_value;) instead of (bool b = int_value != 0;) So long as you're aware of the limitations and usage, it's not an issue. :)

[pbos]

A shorter version would be "#ifndef _Bool", is there any non-standard way about writing that? I know that it works in gcc.

[James Morris]

Just discovered using !! can be very handy in macros sometimes - instead of bitshifting the results of a bitshifted state & bit test.

[James Morris]

I did not expect #ifndef _Bool to work, and nor does it with the gcc (4.3.2 debian) I'm using.

[Michael Aaron Safyan]

What if the header is included from a C++ source file? Better to not use the keywords "bool", "true", and "false" when defining the type.

[Michael Aaron Safyan]

For binary compatibility reasons this might not be as good an idea as it looks. In general, when creating a public C API, it is best to simply use "int" wherever a boolean type is required.

[Matt Joiner]

maybe now it will make sense, i explained a bit.

[pmg]

@Michael: I mostly use C89 and I tend to use int when I need a boolean. I checked sizeof (_Bool) before posting and, as it is 1 that's why I opted for unsigned char in my answer

[pmg]

The Standard (section 6.3.1.2) says: "1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.".

[pbos]

And what we're discussing here is how to implement bool when _Bool is missing.

[Adrien Plisson]

we are talking about C: C does not define a lot of concepts that we have to define ourself. the problem would arise with any identifier which match a C++ keyword: static_cast, this, ...

[Alice]

@MichaelAaronSafyan Untrue. bool, via stdbool.h, is the recommended way by the committee for anyone targeting modern C. Using int as a bool is not advised.

[Michael Aaron Safyan]

@Alice, I agree, that is certainly the right way to use it in one's own code base; however, for functions that are meant to be invoked outside the library and are meant to be an API, it is sometimes useful to use a more limited subset of C for the declaration of those functions in order to allow for a wider variety of clients to be able to use it. That being said, it is fairly subjective, and I could see it being argued both ways.

[Michael Aaron Safyan]

@AdrienPlisson while that's true, C++ code is often a client of libraries written in C, so it would be foolish not to consider it for anything declared in a *.h file that might be used by C++ clients (for C source files, you can do whatever you want without worrying about C++).

[Alice]

@MichaelAaronSafyan If your idea of a limited subset of C is reducing C to a standard more than 20 years out of date, then I believe you may have bigger issues, like the fact someone is apparently running your code on an 8080.

[Michael Aaron Safyan]

There's a pretty big difference between compiler version and OS/library version. Even if you compile something on a modern compiler, there may be cases where a symbol needs to be loaded dynamically (via dlsym or LoadLibrary) or where you are updating code that is linked into other people's libraries that may be compiled on a variety of different compilers or technologies. You seem to be confusing interface and implementation. I am not suggesting you limit yourself in the implementation (or even in internal interfaces), but there is benefit in making uber compatible and stable interfaces.

[Dan Bechard]

@MichaelAaronSafyan That assumes that the OP is writing a library meant to be consumed by C++. It would be foolish to write code as if it were for this purpose if it were not for this purpose.