bison-patches
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]