Joel,
Thanks for the prompt reply.
I've now given your code a much closer look. This behavior is another
manifestation of a complex Bison GLR problem that I've known about for a
while and am still working on. Unfortunately, I don't believe I've
previously posted about it. It touches on man
On Mon, 1 May 2006, Derek M Jones wrote:
> I'm not sure if the following is a feature or a bug.
>
> There are four parses of the C input (x)*sizeof(y);
>
> (x) can be parsed as:
>
>1) a cast of the expression *sizeof(y) to the type x (not
> possible semantically, but this is syntax)
>
> Thanks for the response.
> But I'm not sure I understood what you have mentioned.
> Could you please give an example or a bit more detail?
Sure, (at the risk of being slightly off-topic)...
> > nonterminal X:
> > #ifdef FEATURE
> > { rule 1 }
> > #else
> > { rule 1; rule 2 }
> > #endif
Place
One way of handling this is to merge the two grammars, and making
them selectable by a special token, which is then used at runtime.
The .y grammar is entirely static, and is even thrown away by the LALR
(1) algorithm that Bison uses, so the generated parser does not know
anything about it,
Fang,
Thanks for the response.
But I'm not sure I understood what you have mentioned.
Could you please give an example or a bit more detail?
Appreciate it.
Thanks!
-Original Message-
From: David Fang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 12:55 PM
To: Jeganatan, Srividhya
> Is there a way to conditionally generate grammar rules?
> For example, I need to do something like
>
> nonterminal X:
> #ifdef FEATURE
> { rule 1 }
> #else
> { rule 1; rule 2 }
> #endif
>
> I know that ifdefs dont work with the grammar but is there anything
> else that can be done? Or is it pos
All,
Is there a way to conditionally generate grammar rules?
For example, I need to do something like
nonterminal X:
#ifdef FEATURE
{ rule 1 }
#else
{ rule 1; rule 2 }
#endif
I know that ifdefs dont work with the grammar but is there anything else
that can be done?
Or is it possible to make bi
On 2 May 2006, at 09:48, Akim Demaille wrote:
Le 29 avr. 06 à 19:16, Hans Aberg a écrit :
You do not give much info about what is leaking, so it could just
as well be in your actions. The Bison generated parser used to
leak for various strings that had not been translated from the C-
subs
Joel,
Make sure you are running at least Bison 2.1. If the results still don't
make sense to you, post again and I'll look harder at this.
In the future, please tell us what version of Bison you are running.
Ok, will do. Yes, I am running version 2.1.
--
Derek M. Jones
Le 29 avr. 06 à 19:16, Hans Aberg a écrit :
You do not give much info about what is leaking, so it could just
as well be in your actions. The Bison generated parser used to leak
for various strings that had not been translated from the C-subset
of C++ to say using std::string, but I am not
Le 28 avr. 06 à 23:28, Steve Murphy a écrit :
Hello--
I notice that the parser generated by bison for C has the following
exception:
/* As a special exception, when this file is copied by Bison into a
Bison output file, you may use that output file without
restriction.
This special e
11 matches
Mail list logo
