[Top][All Lists]
[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?
- Re: Bison-2.1 grl :),
Paul Eggert <=