This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
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.
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.
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.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:
Resolved by P0619R4.Proposed resolution: