[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another - Bison 1.35 works but Bison 1.50 Doesn't
From: |
Akim Demaille |
Subject: |
Re: Another - Bison 1.35 works but Bison 1.50 Doesn't |
Date: |
13 Oct 2002 16:31:53 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) |
>>>>> "Paul" == Paul Eggert <address@hidden> writes:
>> Hm... Are you sure we want this? What does POSIX say?
Paul> POSIX says this of both $$ and $1:
Paul> If type checking is enabled and the type of the value to be
Paul> assigned cannot be determined, a diagnostic message may be
Paul> generated.
Paul> So the message is optional for the default action "$$ = $1;".
OK. Still, I'm not fond :( I also matched Byacc's behavior, IIRC.
So just for means of portability to other Yacc's, I think this is a
regression.
Paul> I agree with you in general, but I'm not so sure about this
Paul> particular case. To my mind, that warning was a bit like
Paul> warning about the C statement `close (0);'. In both cases the
Paul> programmer is implicitly discarding a value. But the GNU coding
Paul> standards ask programmers to not write an explicit cast to
Paul> (void) in the C case, implying that such a warning is bogus for
Paul> the C statement. The Bison case seems similar to me. Jim
Paul> Gifford supplied a real grammar where the warning was a false
Paul> alarm. We don't have an exhaustive survey here by any means,
Paul> but I tend to think such cases will dominate the cases where the
Paul> warning is useful.
Paul> I suppose we could enable the extra warning as an option. But
Paul> in the meantime I'd rather omit it.
>> I *fixed* a bug here, before Bison was not complaining for such
>> cases when there was a midrule action, that's the only difference
>> with 1.35.
Paul> Do you have a URL for the bug that you fixed? The fixes
Paul> shouldn't collide, since the fix mentioned above affects only
Paul> the default action, not midrule actions.
What I mean is that I bet that the grammar Jim Gifford reported about
has *all* the other cases fixed but these, because (I have not
checked, this is just by memory) Bison used to check properly
foo: bar baz;
but *not*
foo: bar {} baz;
because the code was written in such a way that the test was fooled by
the presence of a mid-rule action. That's what the following NEWS
item meant:
* Type clashes
Previous versions don't complain when there is a type clash on
the default action if the rule has a mid-rule action, such as in:
%type <foo> bar
%%
bar: '0' {} '0';
This is fixed.
- Another - Bison 1.35 works but Bison 1.50 Doesn't, Jim Gifford, 2002/10/12
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Paul Eggert, 2002/10/12
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Akim Demaille, 2002/10/13
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Paul Eggert, 2002/10/13
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't,
Akim Demaille <=
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Paul Eggert, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Tim Van Holder, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Paul Eggert, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Tim Van Holder, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Akim Demaille, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Akim Demaille, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Akim Demaille, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Paul Eggert, 2002/10/14
- Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Akim Demaille, 2002/10/14
Re: Another - Bison 1.35 works but Bison 1.50 Doesn't, Akim Demaille, 2002/10/13