bug-bison
[Top][All Lists]
Advanced

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

Re: Bison-2.1 grl :)


From: Paul Eggert
Subject: Re: Bison-2.1 grl :)
Date: Wed, 14 Sep 2005 14:17:01 -0700
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

address@hidden writes:

> On Mon, September 12, 2005 9:56 am, Paul Eggert said:
>>> diff -aprNU5 glr.c glr.c.mine
>>> --- glr.c   2005-09-10 10:48:36.637893816 -1000
>>> +++ glr.c.mine      2005-09-10 11:05:56.944743136 -1000
>>> @@ -1666,10 +1666,12 @@ yyresolveValue (yySemanticOption* yyopti
>>>           break;
>>>         case 3:
>>>           yybest = yyp;
>>>           yymerge = yyfalse;
>>>           break;
>>> +       default: /* should not happen */
>>> +         break;
>>
>> Hmm, I don't see the need for this.  The default case is impossible;
>> putting in "default: break;" might confuse readers.
>>
> reasons for wanting that default statement are:
> 1) `default' is needed because of possible gcc warnings
> when extra checkings are done on switch statements

Hmm, I can't reproduce this problem.

> 2) possibly better code generation with some compilers

I don't see why that would be, since an omitted default is the same as
"default: break;".

> 3) indeed that default statement should not happen.

Yes, but that is obvious: all you need to do is look at yypreference.
Since this is merely a style issue, I'd rather leave it alone for now.

> would also suggest to init yydebug in glr.c
> because multiple glr parsers in one program
> works with the rename macros and then every
> glr parser has its own yydebug.
> am using the way how the gettext package runs
> multiple yacc (and glr) parsers in one binary.

Sorry, I don't see the harm in not initializing yydebug.  The C
standard says that if you don't initialize it, it's zero.  Is it that
you're worried about a compiler bug, or is it something else?




reply via email to

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