bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison 1.30f


From: Paul Eggert
Subject: Re: Bison 1.30f
Date: Fri, 14 Dec 2001 10:47:52 -0800 (PST)

> From: Akim Demaille <address@hidden>
> Date: 14 Dec 2001 17:12:22 +0100
> 
> Paul> I think it was one of RMS's original goals when writing Bison.
> 
> `writing Bison' seems a bit excessive to me.

Sorry, my mistake.  I should have said "hacking on Bison".  The area
that we're talking about (support for Yacc) was written by Stallman,
but you're right: the original Bison code was by Robert Corbett.

> But we are referring to different levels of cleanness.
> 
> The next level is cleanness wrt to inside the rules themselves, which
> is what you addressed recently.  I must say that you reach a point
> which seems excessive to me, see for instance yysize when augmenting
> the stacks: this is not inside the any user space at all,

I don't see why that was excessive, because of the problem of
user-defined macros.  For example, if I define a macro like this:

#define size getpagesize ()

then the old Bison code wouldn't work.  And POSIX says that I can
define a macro like that.

> Then, cleanness wrt imported symbols.  To me, this is just impossible.

It's not impossible.  On GNU systems, it works by default.  And now
you can get it to work even if you define YYDEBUG, if you also define
YYFPRINTF.

> Because bison decides to include or stdio.h depending upon options,
> you just cannot safely have your code use stdio.h: risks of
> including it twice, or not at all.

These days there is no real harm to including it twice.  But if it is
a real problem, you can prevent Bison's inclusion by defining
YYFPRINTF and then doing it yourself.

> And now for something completely different: is YYDEBUG (and yydebug) a
> POSIX stuff?

Yes.  I just read through the spec.  It does not talk about the
relationship between YYDEBUG and importing stdio.h symbols at all!
So, strictly speaking, Bison should not include stdio.h even when
YYDEBUG is nonzero.  However, I think this is merely a bug in the
standard, as traditional yacc requires the <stdio.h> symbols, so I
think we're OK here.

On reading the spec I also see we are incompatible with POSIX in one
other minor issue with respect to YYDEBUG.  POSIX says that you need
code like this if the -t option is not present:

#ifndef YYDEBUG
# define YYDEBUG 0
#endif

but Bison doesn't do that.  I'll patch this shortly.

> I suppose -v (generation of the textual representation of the
> automaton) is, right?

Yes.



reply via email to

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