[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %define boolean variables
From: |
Joel E. Denny |
Subject: |
Re: %define boolean variables |
Date: |
Mon, 29 Jan 2007 16:03:20 -0500 (EST) |
On Mon, 29 Jan 2007, Paolo Bonzini wrote:
> > So again, my plan is to remove the value-less form of %define. I'll also
> > rewrite b4_percent_define_flag_if to invoke b4_complain when the user
> > specifies anything other than "true" or "false".
>
> No, please. The reason for this is the parallel with the C preprocessor
> (where, except in Autoconf :-), you define symbols with `#define FOO'.
I don't believe we're paralleling it very closely anyway. In cpp, the
test to see if a macro is defined and the test to see if it is true (a
non-zero integer) are different. In CVS Bison, they're currently the
same: b4_percent_define_flag_if. In cpp, unless "true" (I mean a macro
name not a string) is defined as some non-zero integer, "true" is false.
In cpp, some random "foo" is probably undefined and is therefore seen as
false. But Bison treats a non-zero integer, "true", and "foo" as all
true.
I'm trying to remember if I've ever seen a C program with a cpp macro for
which values of non-zero integer, "true", and "" are true but "0" and
"false" are false. I can't think of one. At the moment, I can't think of
how you'd even write that test because I can't think of how you check for
the empty string. Sorry if I'm being ignorant.
Why do you want to mimic cpp anyway?
> As a compromise, if you keep the current behavior of empty being true, and
> `%define FOO' aliasing `%define FOO ""', it's ok for me to complain on
> anything but empty/"true"/"false", including making "0" or "1" invalid.
I think that's a significant improvement because it gets rid of an
infinite number of confusing possible values. I can agree to this
compromise.
Re: %define boolean variables, Paolo Bonzini, 2007/01/29