2155. Macro __bool_true_false_are_defined should be removed

Section: 17.13 [support.runtime] Status: Resolved Submitter: Thomas Plum Opened: 2012-04-30 Last modified: 2020-11-09

Priority: 4

View all other issues in [support.runtime].

View all issues with Resolved status.

Discussion:

Since C99, the C standard describes a macro named __bool_true_false_are_defined.

In the process of harmonizing C++11 with C99, this name became part of the C++ standard.

I propose that all mention of this name should be removed from the C and C++ standards.

Here's the problem: The name was originally proposed as a transition tool, so that the headers for a project could contain lines like the following.

#if !defined(__bool_true_false_are_defined)
#define bool int /* or whatever */
#define true 1
#define false 0
#endif

Then when the project was compiled by a "new" compiler that implemented bool as defined by the evolving C++98 or C99 standards, those lines would be skipped; but when compiled by an "old" compiler that didn't yet provide bool, true, and false, then the #define's would provide a simulation that worked for most purposes.

It turns out that there is an unfortunate ambiguity in the name. One interpretation is as shown above, but a different reading says "bool, true, and false are #define'd", i.e. that the meaning of the macro is to assert that these names are macros (not built-in) ... which is true in C, but not in C++.

In C++11, the name appears in parentheses followed by a stray period, so some editorial change is needed in any event:

17.13 [support.runtime] para 1:

Headers <csetjmp> (nonlocal jumps), <csignal> (signal handling), <cstdalign> (alignment), <cstdarg> (variable arguments), <cstdbool> (__bool_true_false_are_defined). <cstdlib> (runtime environment getenv(), system()), and <ctime> (system clock clock(), time()) provide further compatibility with C code.

However, para 2 says

"The contents of these headers are the same as the Standard C library headers <setjmp.h>, <signal.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stdlib.h>, and <time.h>, respectively, with the following changes:",

and para 8 says

"The header <cstdbool> and the header <stdbool.h> shall not define macros named bool, true, or false."

Thus para 8 doesn't exempt the C++ implementation from the arguably clear requirement of the C standard, to provide a macro named __bool_true_false_are_defined defined to be 1.

Real implementations of the C++ library differ, so the user cannot count upon any consistency; furthermore, the usefulness of the transition tool has faded long ago.

That's why my suggestion is that both C and C++ standards should eliminate any mention of __bool_true_false_are_defined. In that case, the name belongs to implementers to provide, or not, as they choose.

[2013-03-15 Issues Teleconference]

Moved to Open.

While not strictly necessary, the clean-up look good.

We would like to hear from our C liaison before moving on this issue though.

[2015-05 Lenexa]

LWG agrees. Jonathan provides wording.

[2017-03-04, Kona]

The reference to <cstdbool> in p2 needs to be struck as well. Continue the discussion on the reflector once the DIS is available.

Previous resolution [SUPERSEDED]:

This wording is relative to N4296.

1. Edit the footnote on 16.4.2.3 [headers] p7:

   176) In particular, including any of the standard headers <stdbool.h>, <cstdbool>, <iso646.h> or <ciso646> has no effect.

2. Edit 17.13 [support.runtime] p1 as indicated (and remove the index entry for __bool_true_false_are_defined):

   -1- Headers <csetjmp> (nonlocal jumps), <csignal> (signal handling), <cstdalign> (alignment), <cstdarg> (variable arguments), <cstdbool>, (__bool_true_false_are_defined). <cstdlib> (runtime environment getenv(), system()), and <ctime> (system clock clock(), time()) provide further compatibility with C code.

3. Remove Table 38 — Header <cstdbool> synopsis [tab:support.hdr.cstdbool] from 17.13 [support.runtime]

   Table 38 — Header <cstdbool> synopsis

   Type	Name(s)
   Macro:	__bool_true_false_are_defined

[2019-03-18; Daniel comments and eliminates previously proposed wording]

With the approval of P0619R4 in Rapperswil, the offending wording has now been eliminated from the working draft. I suggest to close this issue as: Resolved by P0619R4.

[2020-11-09 Resolved for C++20. Status changed: Tentatively Resolved → Resolved.]

Rationale:

Proposed resolution: