[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: assert failure at line 1896
From: |
Joel E. Denny |
Subject: |
Re: assert failure at line 1896 |
Date: |
Tue, 30 May 2006 01:23:09 -0400 (EDT) |
On Mon, 29 May 2006, Paul Eggert wrote:
> "Joel E. Denny" <address@hidden> writes:
>
> > Searching for `#define' in the Open Group's yacc spec, I see no
> > discussion of the yacc user ever specifying a #define.
>
> You missed YYDEBUG.
Thanks, I did miss it.
> > So, macros should be only a Bison backward-compatibility issue, right?
>
> If by that you mean "macros defined by the user whose names begin
> with yy or YY"
Yes, that's what I meant.
>, then I would demur for the following macros:
>
> YYDEBUG
> YYMAXDEPTH
> YYSTYPE
>
> since Solaris 10 yacc generates a parser whose behavior also depend on
> these user-defined macros, in a way that's compatible with Bison.
The first two don't bother me so much since they're usually just integers,
right? I guess putting a complex expression in there is possible, but I
wonder if that's really anything to worry about.
It's more complex declarations like YYSTYPE that can be troublesome. I
wonder if we could support #define YYSTYPE just for yacc.c and only
typedef elsewhere. Then again, if we have to support it in yacc.c, then
we have to support it in everything that both it and other skeletons
depend upon (like c.m4), and so it might not be worth the trouble to
deprecate it at all.
Well, this is beyond me for now.
Joel
- Re: assert failure at line 1896, (continued)
Re: assert failure at line 1896, Akim Demaille, 2006/05/29
Re: assert failure at line 1896, Paul Eggert, 2006/05/30
Re: assert failure at line 1896,
Joel E. Denny <=
Re: assert failure at line 1896, Paul Eggert, 2006/05/21