I get the error
‘CHAR_WIDTH’ undeclared
when I try to compile this simple program:
#include <stdio.h>
#include <limits.h>
int main()
{
printf("CHAR_BIT = %d\n", CHAR_BIT);
printf("CHAR_WIDTH = %d\n", CHAR_WIDTH);
return (0);
}
with
gcc ./show_char_width.c -o show_char_width
and gcc: GNU C17 (Ubuntu 8.3.0-6ubuntu1) version 8.3.0 (x86_64-linux-gnu) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP,
kernel: 5.0.0-37-generic.
As stated here CHAR_WIDTH should be defined in limits.h which is included in my program. So why I get this error?
With the -v option I found that the library will be searched in those directories:
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed contain a limits.h that include syslimits.h from the same dir which in turn include the next limits.h, that from my understanding should be located in the /usr/include directory.
The CHAR_WIDTH macro is indeed defined in those files but under some conditions that exceed my actual knowledge.
The conditions I found untill now are:
/* The integer width macros are not defined by GCC's <limits.h> before
GCC 7, or if _GNU_SOURCE rather than
__STDC_WANT_IEC_60559_BFP_EXT__ is used to enable this feature. */
#if __GLIBC_USE (IEC_60559_BFP_EXT)
# ifndef CHAR_WIDTH
# define CHAR_WIDTH 8
# endif
and :
#ifdef __STDC_WANT_IEC_60559_BFP_EXT__
/* TS 18661-1 widths of integer types. */
# undef CHAR_WIDTH
# define CHAR_WIDTH __SCHAR_WIDTH__
That's why I need your help.
Note: I get the same error with all other macros described in A.5.1 notably: SCHAR_WIDTH, INT_WIDTH, LONG_WIDTH, etc.
CHAR_WIDTH isn't standard, nor are any other *_WIDTH macros, but the width of a character type must be the same as CHAR_BIT anyway*.
As for *_WIDTH macros in general, they aren't strictly needed as they are compile-time-computable from the maximum value of the corresponding unsigned type, i.e., you can have a #define WIDTH_FROM_UNSIGNED_MAX(UnsignedMax) that expands to an integer constant expression that's also usable in preprocessor conditionals (#if), though implementations are a little bit obscure (see Is there any way to compute the width of an integer type at compile-time?), e.g.:
#define WIDTH_FROM_UNSIGNED_MAX(UnsignedMax) POW2_MINUS1_BITS_2039(UnsignedMax)
/* Number of bits in inttype_MAX, or in any (1<<k)-1 where 0 <= k < 2040 */
#define POW2_MINUS1_BITS_2039(X) ((X)/((X)%255+1) / 255%255*8 + 7-86/((X)%255+12))
//compile-time test it, assuming uint{8,16,32,64}_t exist
#include <inttypes.h>
#if WIDTH_FROM_UNSIGNED_MAX(UINT8_MAX) != 8
#error
#endif
#if WIDTH_FROM_UNSIGNED_MAX(UINT16_MAX) != 16
#error
#endif
#if WIDTH_FROM_UNSIGNED_MAX(UINT32_MAX) != 32
#error
#endif
#if WIDTH_FROM_UNSIGNED_MAX(UINT64_MAX) != 64
#error
#endif
Some people just do CHAR_BIT * sizeof(integer_type), but that isn't strictly portable, because it assumes integer_type doesn't have padding bits (it usually doesn't but theoretically it can have them), and can't use it in #if conditionals either.
*Unfortunately, to glean this info, you need jump all over the standard:
The width of an integer type is (slightly indirectly) defined as the number of its nonpadding bits (6.2.6.2p6).
6.2.6.2p2 says signed char doesn't have any padding bits. Because of how integers can be represented in C (6.2.6.2p2), that implies unsigned char can't have any padding bits either, and since char must have the same limits as either signed char or unsigned char (5.2.4.2.1p2) while having the same sizeof value (namely 1, 6.5.3.4p4), a plain char can't have any padding bits either, and so CHAR_BIT == width of (char|signed char|unsigned char).
Related
I'm working on building a custom version of openwrt with a build tool and keep running into a error I cant seem to fix.
heres the code block its dating back to.
#include <signal.h>
#if ! HAVE_STACK_T && ! defined stack_t
typedef struct sigaltstack stack_t;
#endif
#ifndef SIGSTKSZ
# define SIGSTKSZ 16384
#elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
/* libsigsegv 2.6 through 2.8 have a bug where some architectures use
more than the Linux default of an 8k alternate stack when deciding
if a fault was caused by stack overflow. */
# undef SIGSTKSZ
# define SIGSTKSZ 16384
#endif
heres the out put error
In file included from /usr/include/signal.h:328,
from ./signal.h:52,
from c-stack.c:49:
c-stack.c:55:26: error: missing binary operator before token "("
55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
| ^~~~~~~~
First of all please note that this is not standard C but POSIX extensions. POSIX has the nasty habit of poisoning standard libraries with non-standard, non-conforming extensions.
This means that if you compile with -std=c17 or equivalent instead of -std=gnu17 (default), gcc will strip off all non-standard, non-conforming POSIX junk. And then those things will not be found at all even if you include signal.h, which in turn can give you very confusing compiler errors.
That being said, I think you perhaps meant to do:
#elif defined(HAVE_LIBSIGSEGV) && SIGSTKSZ < 16384
As for how you can find out what SIGSTKSZ is without digging through some library header, here's a simple trick that gives you the exact macro definition:
#include <stdio.h>
#include <signal.h>
#define STR(s) #s
#define WHAT_ARE_YOU(x) puts(STR(x))
int main (void)
{
WHAT_ARE_YOU(SIGSTKSZ);
}
When compiling as GNU C on some random Linux machine, I get 8192.
You could also do gcc -E to view the preprocessor output (which may be a bit confusing to read since it expands all headers). Doing that for the above example gives puts("8192");.
I'm trying to write a portable program that deals with ustar archives. For device files, these archives store the major and minor device numbers. However, the struct stat as laid out in POSIX only contains a single st_rdev member of type dev_t described with “Device ID (if file is character or block special).”
How can I convert between a pair of major and minor device numbers and a single st_rdev member as returned by stat() in a portable manner?
While all POSIX programming interfaces use the device number (of type dev_t) as is, FUZxxl pointed out in a comment to this answer that the common UStar file format -- most common tar archive format -- does split the device number into major and minor. (They are typically encoded as seven octal digits each, so for compatibility reasons one should limit to 21-bit unsigned major and 21-bit unsigned minor. This also means that mapping the device number to just the major or just the minor is not a reliable approach.)
The following include file expanding on Jonathon Reinhart's answer, after digging on the web for the various systems man pages and documentation (for makedev(), major(), and minor()), plus comments to this question.
#if defined(custom_makedev) && defined(custom_major) && defined(custom_minor)
/* Already defined */
#else
#undef custom_makedev
#undef custom_major
#undef custom_minor
#if defined(__linux__) || defined(__GLIBC__)
/* Linux, Android, and other systems using GNU C library */
#ifndef _BSD_SOURCE
#define _BSD_SOURCE 1
#endif
#include <sys/types.h>
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#elif defined(_WIN32)
/* 32- and 64-bit Windows. VERIFY: These are just a guess! */
#define custom_makedev(dmajor, dminor) ((((unsigned int)dmajor << 8) & 0xFF00U) | ((unsigned int)dminor & 0xFFFF00FFU))
#define custom_major(devnum) (((unsigned int)devnum & 0xFF00U) >> 8)
#define custom_minor(devnum) ((unsigned int)devnum & 0xFFFF00FFU)
#elif defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) || defined(__DragonFly__)
/* FreeBSD, OpenBSD, NetBSD, and DragonFlyBSD */
#include <sys/types.h>
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#elif defined(__APPLE__) && defined(__MACH__)
/* Mac OS X */
#include <sys/types.h>
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#elif defined(_AIX) || defined (__osf__)
/* AIX, OSF/1, Tru64 Unix */
#include <sys/types.h>
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#elif defined(hpux)
/* HP-UX */
#include <sys/sysmacros.h>
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#elif defined(sun)
/* Solaris */
#include <sys/types.h>
#include <sys/mkdev.h>
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#else
/* Unknown OS. Try a the BSD approach. */
#ifndef _BSD_SOURCE
#define _BSD_SOURCE 1
#endif
#include <sys/types.h>
#if defined(makedev) && defined(major) && defined(minor)
#define custom_makedev(dmajor, dminor) makedev(dmajor, dminor)
#define custom_major(devnum) major(devnum)
#define custom_minor(devnum) minor(devnum)
#endif
#endif
#if !defined(custom_makedev) || !defined(custom_major) || !defined(custom_minor)
#error Unknown OS: please add definitions for custom_makedev(), custom_major(), and custom_minor(), for device number major/minor handling.
#endif
#endif
One could glean additional definitions from existing UStar-format -capable archivers. Compatibility with existing implementations on each OS/architecture is, in my opinion, the most important thing here.
The above should cover all systems using GNU C library, Linux (including Android), FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, Mac OS X, AIX, Tru64, HP-UX, and Solaris, plus any that define the macros when <sys/types.h> is included. Of the Windows part, I'm not sure.
As I understand it, Windows uses device 0 for all normal files, and a HANDLE (a void pointer type) for devices. I am not at all sure whether the above logic is sane on Windows, but many older systems put the 8 least significant bits of the device number into minor, and the next 8 bits into major, and the convention seems to be that any leftover bits would be put (without shifting) into minor, too. Examining existing UStar-format tar archives with references to devices would be useful, but I personally do not use Windows at all.
If a system is not detected, and the system does not use the BSD-style inclusion for defining the macros, the above will error out stopping the compilation. (I would personally add compile-time machinery that could help finding the correct header definitions, using e.g. find, xargs, and grep, in case that happens, with a suggestion to send the addition upstream, too. touch empty.h ; cpp -dM empty.h ; rm -f empty.h should show all predefined macros, to help with identifying the OS and/or C library.)
Originally, POSIX stated that dev_t must be an arithmetic type (thus, theoretically, it might have been some variant of float or double on some systems), but IEEE Std 1003.1, 2013 Edition says it must be an integer type. I would wager that means no known POSIX-y system ever used a floating-point dev_t type. It would seem that Windows uses a void pointer, or HANDLE type, but Windows is not POSIX-compliant anyway.
Use the major() and minor() macros after defining BSD_SOURCE.
The makedev(), major(), and minor() functions are not specified in
POSIX.1, but are present on many other systems.
http://man7.org/linux/man-pages/man3/major.3.html
I have a program based on an antique version of ls for Minix, but much mangled modified by me since then. It has the following code to detect the major and minor macros — and some comments about (now) antique systems where it has worked in the past. It assumes a sufficiently recent version of GCC is available to support #pragma GCC diagnostic ignored etc. You have to be trying pretty hard (e.g. clang -Weverything) to get the -Wunused-macros option in effect unless you include it explicitly.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-macros"
/* Defines to ensure major and minor macros are available */
#define _DARWIN_C_SOURCE /* In <sys/types.h> on MacOS X */
#define _BSD_SOURCE /* In <sys/sysmacros.h> via <sys/types.h> on Linux (Ubuntu 12.0.4) */
#define __EXTENSIONS__ /* Maybe beneficial on Solaris */
#pragma GCC diagnostic pop
/* From Solaris 2.6 sys/sysmacros.h
**
** WARNING: The device number macros defined here should not be used by
** device drivers or user software. [...] Application software should make
** use of the library routines available in makedev(3). [...] Macro
** routines bmajor(), major(), minor(), emajor(), eminor(), and makedev()
** will be removed or their definitions changed at the next major release
** following SVR4.
**
** #define O_BITSMAJOR 7 -- # of SVR3 major device bits
** #define O_BITSMINOR 8 -- # of SVR3 minor device bits
** #define O_MAXMAJ 0x7f -- SVR3 max major value
** #define O_MAXMIN 0xff -- SVR3 max major value
**
** #define L_BITSMAJOR 14 -- # of SVR4 major device bits
** #define L_BITSMINOR 18 -- # of SVR4 minor device bits
** #define L_MAXMAJ 0x3fff -- SVR4 max major value
** #define L_MAXMIN 0x3ffff -- MAX minor for 3b2 software drivers.
** -- For 3b2 hardware devices the minor is restricted to 256 (0-255)
*/
/* AC_HEADER_MAJOR:
** - defines MAJOR_IN_MKDEV if found in sys/mkdev.h
** - defines MAJOR_IN_SYSMACROS if found in sys/macros.h
** - otherwise, hope they are in sys/types.h
*/
#if defined MAJOR_IN_MKDEV
#include <sys/mkdev.h>
#elif defined MAJOR_IN_SYSMACROS
#include <sys/sysmacros.h>
#elif defined(MAJOR_MINOR_MACROS_IN_SYS_TYPES_H)
/* MacOS X 10.2 - for example */
/* MacOS X 10.5 requires -D_DARWIN_C_SOURCE or -U_POSIX_C_SOURCE - see above */
#elif defined(USE_CLASSIC_MAJOR_MINOR_MACROS)
#define major(x) ((x>>8) & 0x7F)
#define minor(x) (x & 0xFF)
#else
/* Hope the macros are in <sys/types.h> or otherwise magically visible */
#endif
#define MAJOR(x) ((long)major(x))
#define MINOR(x) ((long)minor(x))
You will justifiably not be all that keen on the 'hope the macros are … magically visible' part of the code.
The reference to AC_HEADER_MAJOR is to the macro in the autoconf that deduces this information. It would be relevant if you have a config.h file generated by autoconf.
POSIX
Note that the POSIX pax command defines the ustar format and specifies that it includes devmajor and devminor in the information, but adds:
… Represent character special files and block special files respectively. In this case the devmajor and devminor fields shall contain information defining the device, the format of which is unspecified by this volume of POSIX.1-2008. Implementations may map the device specifications to their own local specification or may ignore the entry.
This means that there isn't a fully portable way to represent the numbers. This is not wholly unreasonable (but it is a nuisance); the meanings of the major and minor device numbers varies across platforms and is unspecified too. Any attempt to create block or character devices via ustar format will only work reasonably reliably if the source and target machines are running the same (version of the same) operating system — though usually they're portable across versions of the same operating system.
Here is my dead simple dummy code:
#include <errno.h>
int main(void)
{
errno_t e;
return 0;
}
Which surprisingly raises this error:
main.c:5:5: error: use of undeclared identifier 'errno_t'
errno_t x;
^
I started to follow the traces: when the compiler sees the <...> inclusions it will first look at /usr/include where of course I found errno.h file. Actually it has a single line in it, besides the license comment, which is:
#include <sys/errno.h>
Now, at /usr/include/sys in errno.h I found the following lines:
#include <sys/cdefs.h>
#if defined(__STDC_WANT_LIB_EXT1__) && __STDC_WANT_LIB_EXT1__ >= 1
#include <sys/_types/_errno_t.h>
#endif
And at /usr/include/_types in _errno_t.h I found this:
typedef int errno_t;
So it looks like, it is there, and it is an alias of the integer type, and part of the errno.h -- just as it should be.
Then why isn't it included? Why the compiler raises the undeclared identifier error?
Thanks in advance!
RELEVANT INFO:
Compiler:
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)`
Compiler flags:
-std=c11 -I/usr/include/sys -I/usr/local/include
The macro variable __STDC_WANT_LIB_EXT1__ will be defined at /usr/include/sys in cdefs.h in the following lines:
/* If the developer has neither requested a strict language mode nor a version
* of POSIX, turn on functionality provided by __STDC_WANT_LIB_EXT1__ as part
* of __DARWIN_C_FULL.
*/
#if !defined(__STDC_WANT_LIB_EXT1__) && !defined(__STRICT_ANSI__) && __DARWIN_C_LEVEL >= __DARWIN_C_FULL
#define __STDC_WANT_LIB_EXT1__ 1
#endif
UPDATE:
As #PaulR said in the comment section: if I remove the -std=c11 flag, it compiles. Which is just as surprising as the error raised if the flag was included. So I extend this question with a sub-question:
Is not errno_t part of the C11 standard, or why isn't it included, when the standard is specified for the compiler?
errno_t is not a standard type; it's part of the optional (and widely disliked and unsupported) Annex K, included with ISO C11 only because of one particular vendor with a history of ignoring and sabotaging the standard.
Since Annex K defines errno_t as int, the type of the errno object is int, and all error codes are int, simply use int in your programs. It's much more portable than relying on an optional feature which is unlikely to be supported.
I'm writing a program for my study and therefore I have to descripe a few wars to get the limits of some data types.
When I'm writing this:
#include <limits.h>
#include <stdio.h>
int main(void)
{
printf("%d\n", CHAR_BIT);
printf("%d\n", LONG_BIT);
return 0;
}
but it gives me the following error:
a.c: In function ‘main’:
a.c:7:17: error: ‘LONG_BIT’ undeclared (first use in this function)
printf("%d\n", LONG_BIT);
^
a.c:7:17: note: each undeclared identifier is reported only once for each function it appears in
even gcc -E gives me this
int main(void)
{
printf("%d\n", 8);
printf("%d\n", LONG_BIT);
return 0;
}
But a grep in limits.h doesn't give me the answer. But bits/xopen_lim.h has this declaration and it should be included when
__USE_XOPEN
is declared, but even a manual declaration won't give me a result.
So where is the problem? A look in the manpage says there is a LONG_BIT macro but gcc says no.
gcc version 4.8.0 (GCC)
OS arch
[edit]
For those who say LONG_BIT is not a c-standard, type
man 0 limits.h
and search for LONG_BIT. For me there are two entries under Numerical Limits and therefore I think LONG_BIT exist.
And no, including bits/xopen_lim.h is not realy an option, because it should be included by limits.h and not manually
Your issue is that you shouldn't be defining __USE_XOPEN. If you take a look at /usr/include/features.h you will see it explicitly undefines it and then redefines these macros based on feature test macros. You probably want to define _XOPEN_SOURCE instead, something like:
gcc -D_XOPEN_SOURCE=700 -o longbit longbit.c
From features.h:
_XOPEN_SOURCE Includes POSIX and XPG things. Set to 500 if
Single Unix conformance is wanted, to 600 for the
sixth revision, to 700 for the seventh revision.
_XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix
extensions.
Also, wrt directly including xopen_lim.h:
/*
* Never include this file directly; use <limits.h> instead.
*/
So, I wouldn't recommend directly including it. Also, see man feature_test_macros or info '(libc)Feature Test Macros'.
LONG_BIT is not a thing in standard C.
For a portable approach, just do this:
CHAR_BIT * sizeof(long)
http://www.cplusplus.com/reference/climits/
There is nothing as such LONG_BIT in limits.h
I understand that the config.h header file should be considered to be an internal header file. Now I wonder how to publish something that depends on config.h settings without publishing the config.h itself.
Say, I have a public function returning bool, i.e. depending on either stdbool.h or any appropriate definition of bool. It should be declared within a public header, but this header may be used in an environment without stdbool.h and maybe even without config.h or with a config.h saying nothing about the presence of bool.
I came up with an unsatisfactory solution like this:
#if HAVE_STDBOOL_H || !HAVE_CONFIG_H
# include <stdbool.h>
#endif
#if !__bool_true_false_are_defined
# if !HAVE__BOOL
typedef int _Bool;
# endif
typedef _Bool bool;
# define true (bool)1
# define false (bool)0
#endif
extern bool public_bool(void);
This should work in most standard cases but may fail in many others.
Maybe it's obsolete taking environments without stdbool.h into consideration at all today (I don't know), but this is just a sample of my comprehension gap concerning the autotool-thing. What is the best practice to deal with the problem in general?
In the specific case of <stdbool.h>, we chose to avoid depending on config.h and to rely on the C (or C++) compiler to tell us what is OK. The code includes this header, and this header sorts out the mess. It is known to work on Mac OS X, Linux, Solaris, HP-UX, AIX, Windows. The actual header file name is not ourbool.h, but I've mangled its header guards and comments so it looks as if that is what it is called. The comments quote the C99 standard for the licence to perform as it does. Note that it also works correctly if <stdbool.h> has already been included, and it works correctly if <stdbool.h> is included after it has been included (and getting this correct was not 100% pain-free). Defining __bool_true_false_are_defined is crucial to this inter-working. (When your code is in use by other people, you can't mandate that they do not use <stdbool.h> themselves, either before or after your header is included.)
#ifndef OURBOOL_H_INCLUDED
#define OURBOOL_H_INCLUDED
/*
** Ensure that type bool with constants false = 0 and true = 1 are defined.
** C++ (ISO/IEC 14882:1998/2003/2011) has bool, true and false intrinsically.
** C (ISO/IEC 9899:1999) has bool, true and false by including <stdbool.h>
** C99 <stdbool.h> also defines __bool_true_false_are_defined when included
** MacOS X <dlfcn.h> manages to include <stdbool.h> when compiling without
** -std=c89 or -std=c99 or -std=gnu89 or -std=gnu99 (and __STDC_VERSION__
** is not then 199901L or later), so check the test macro before defining
** bool, true, false. Tested on MacOS X Lion (10.7.1) and Leopard (10.5.2)
** with both:
** #include "ourbool.h"
** #include <stdbool.h>
** and:
** #include <stdbool.h>
** #include "ourbool.h"
**
** C99 (ISO/IEC 9899:1999) says:
**
** 7.16 Boolean type and values <stdbool.h>
** 1 The header <stdbool.h> defines four macros.
** 2 The macro
** bool
** expands to _Bool.
** 3 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.
** 4 Notwithstanding the provisions of 7.1.3, a program may undefine and
** perhaps then redefine the macros bool, true, and false.213)
**
** 213) See 'future library directions' (7.26.7).
**
** 7.26.7 Boolean type and values <stdbool.h>
** 1 The ability to undefine and perhaps then redefine the macros bool, true,
** and false is an obsolescent feature.
**
** Use 'unsigned char' instead of _Bool because the compiler does not claim
** to support _Bool. This takes advantage of the license of paragraph 4.
*/
#if !defined(__cplusplus)
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#elif !defined(__bool_true_false_are_defined)
#undef bool
#undef false
#undef true
#define bool unsigned char
#define false 0
#define true 1
#define __bool_true_false_are_defined 1
#endif
#endif /* !_cplusplus */
#endif /* OURBOOL_H_INCLUDED */
Clearly, if you want to allow for the possibility of HAVE_STDBOOL_H, you may, but it is not needed. You can also decide what to do if HAVE_CONFIG_H is defined, but again it is not needed.
To use this, your header would contain:
#ifndef YOURHEADER_H_INCLUDED
#define YOURHEADER_H_INCLUDED
...other #includes as needed...
#include "ourbool.h" /* Or #include "project/ourbool.h" */
...other material...
extern bool boolean_and(bool lhs, bool rhs);
...other material...
#endif /* YOURHEADER_H_INCLUDED */
The precise location of ourbool.h in yourheader.h is not critical as long as it is before you declare types, functions or (perish the thought) variables that use the bool type.
Defining bool, true, and false yourself in a publicly installed header in the event that stdbool.h was not detected at your configure time seems like a very bad idea. In this particular situation, I think the solution is that unless you can assume your library's users will all have conforming C99 or later environments, you shouldn't be using bool as part of the public interface. Using int, like all idiomatic C code does, would make the problem go away entirely.
With that said, there's also a general issue to be addressed that applies in cases not related to bool where there may be a legitimate need for installed headers to behave differently depending on the environment the library was configured for. In that case, I think the best solution is to have your header be a generated file created by your build system (e.g. mylib.h.in with autoconf) that's setup to match the system it's built for.