[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Calling two times yyparse reloading yyin
From: |
Tim Van Holder |
Subject: |
Re: Calling two times yyparse reloading yyin |
Date: |
Wed, 30 Nov 2005 08:46:18 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.6 (Windows/20050716) |
Ismael Moreno wrote:
> First of all, i've included an "old" version of this piece of code. I fixed
> after ask the yyin field, so sorry.
>
> Well, after using yyrestart and all what you said, now looks like the
> problem is in the first yyparse() function.
>
> I made an diagram with an "assigment" node as a testcase. This diagrams
> represents a very easy algorithm which returns 2+2. The assigment node
> contanis:
> Result <- 2+2
> Where "2+2" is the RValue and "Result" the LValue. It returns an exception:
> "basic_string::_S_construct NULL not valid".
> I've added debug tasks on the lex rules, so, where a token is identified, it
> shows in the console what token is under processing. In RValue, only the
> first number token is recognized.
> It is really odd, since i've made earlier some parsers with a different yyin
> from stdio.
> That's the remodeled piece of code:
>
> *//RValue*
> yyin = fmemopen(Text, strlen(Text) , "r");
> *if*(yyin == NULL)
> *throw*(cError("you-know-that"));
>
> yyrestart(yyin);
> yyparse();
> sMemReg Instr;
> Instr.Func = push_ax;
> vm.putMemoryCell(Instr);
>
> *//LValue (...)*
At this point we would have to see the lexer source, and perhaps also
the relevant grammar rules.
But this seems to have moved from a bison/flex question to a bug hunt,
so it would probably be best if you used a debugger to trace
where the exception happens (since neither flex nor bison use C++
strings, the error has to be in user code somewhere, with the exception
suggesting that you're constructing a string using a char* that is
NULL).