Title
Macro __bool_true_false_are_defined should be removed
Status
resolved
Section
[support.runtime]
Submitter
Thomas Plum

Created on 2012-04-30.00:00:00 last changed 50 months ago

Messages

Date: 2020-11-09.22:09:58
Resolved by

Rationale:

P0619R4.
Date: 2020-11-09.00:00:00

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

Date: 2019-03-15.00:00:00

[ 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.

Date: 2017-03-15.00:00:00

[ 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 [headers] p7:

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

  2. Edit [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 [support.runtime]

    Table 38 — Header <cstdbool> synopsis
    TypeName(s)
    Macro:__bool_true_false_are_defined
Date: 2015-05-08.17:03:03

[ 2015-05 Lenexa ]

LWG agrees. Jonathan provides wording.

Date: 2013-03-15.00:00:00

[ 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.

Date: 2012-04-30.00:00:00

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:

[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.

History
Date User Action Args
2020-11-09 22:09:58adminsetmessages: + msg11595
2019-03-23 12:04:39adminsetmessages: + msg10376
2019-03-23 12:04:39adminsetstatus: open -> resolved
2017-03-14 03:25:42adminsetmessages: + msg9121
2015-05-08 17:03:03adminsetmessages: + msg7408
2015-05-08 17:03:03adminsetmessages: + msg7407
2013-03-18 14:33:00adminsetmessages: + msg6409
2013-03-18 13:02:36adminsetstatus: new -> open
2012-04-30 00:00:00admincreate