Re: TRUE and FALSE

Andy Lester <andy@petdance.com> wrote:
> Why do we have the TRUE and FALSE macros?

The core long predates a standardised boolean type in C, so these
macros allowed expressing intention better than raw 0 or 1.

Commit 8d063cd8450e59ea1c611a2f4f5a21059a2804f1 (Perl 1, December
1987) contains these lines in handy.h:

#define bool char
#define TRUE (1)
#define FALSE (0)

C99 added a standard type _Bool that can store only the values 0 and 1
(plus a <stdbool.h> header that defines names bool, true, false), and
when Perl is built using a suitable compiler, the "bool" type defined
by handy.h is the standard one.

The main reason for the cBOOL() macro to exist is that, if the bool
type in handy.h isn't C99 _Bool, code like "bool b = (bool) some_expr"
might store a value other than 0 or 1 in b. (In addition, it's defined
in a slightly non-obvious way to work around idiosyncrasies in certain
compilers.)

> Is the intent that if we use a bool type anywhere that they will be set using TRUE and FALSE or cBOOL()?

No, that isn't considered compulsory.

> I'm not seeing anything in pod/perlhack*.pod that discusses them.
>
> I see plenty of code like:
>
> bool have_branch = 0;
> bool skip = 1;

These could have used TRUE/FALSE as a way of clarifying intent. My
view is that the combination of the type name and a simple 0-or-1
literal is good enough on that score, so changing such usages would
just be needless churn.

> const bool utf8_target = (sv && SvUTF8(sv)) ? 1 : 0;

This is effectively a reimplementation of cBOOL(), so could have been
the slightly shorter cBOOL(sv && SvUTF8(sv)). But, again, I'm not
convinced that it would be worth changing working code.

Would this patch to perlhacktips.pod clarify the situation adequately for you?

commit 18f28fb48319b6775c6bf5dd6c00f0926506a9d1
Author: Aaron Crane <arc@cpan.org>
Date:   Mon Jan 2 15:12:45 2017 +0000

    perlhacktips: add some notes on TRUE and FALSE

diff --git a/pod/perlhacktips.pod b/pod/perlhacktips.pod
index 8b3392d..e12e81c 100644
--- a/pod/perlhacktips.pod
+++ b/pod/perlhacktips.pod
@@ -1627,8 +1627,10 @@ bugs in the past.
 =head2 When is a bool not a bool?

 On pre-C99 compilers, C<bool> is defined as equivalent to C<char>.
-Consequently assignment of any larger type to a C<bool> is unsafe and may
-be truncated.  The C<cBOOL> macro exists to cast it correctly.
+Consequently assignment of any larger type to a C<bool> is unsafe and may be
+truncated.  The C<cBOOL> macro exists to cast it correctly; you may also find
+that using it is shorter and clearer than writing out the equivalent
+conditional expression longhand.

 On those platforms and compilers where C<bool> really is a boolean (C++,
 C99), it is easy to forget the cast.  You can force C<bool> to be a C<char>
@@ -1640,6 +1642,10 @@ run C<Configure> with something like
 or your compiler's equivalent to make it easier to spot any unsafe truncations
 that show up.

+The C<TRUE> and C<FALSE> macros are available for situations where using them
+would clarify intent. (But they always just mean the same as the integers 1 and
+0 regardless, so using them isn't compulsory.)
+
 =head2 The .i Targets

 You can expand the macros in a F<foo.c> file by saying

-- 
Aaron Crane ** http://aaroncrane.co.uk/

• TRUE and FALSE by Andy Lester
• Re: TRUE and FALSE by Aaron Crane
• Re: TRUE and FALSE by Andy Lester
• Re: TRUE and FALSE by Aaron Crane