Le 21 juil. 2010 à 23:15, Panayiotis Karabassis a écrit :
Hi!
Well, it turns out it was a missing YYSTYPE definition from the parser file.
Thus defaulting to int and having yystate accidentally overwritten on
updating yylval. A difficult bug.
I might be missing something, but I don't
On 07/22/2010 01:55 PM, Akim Demaille wrote:
Le 21 juil. 2010 à 23:15, Panayiotis Karabassis a écrit :
Hi!
Well, it turns out it was a missing YYSTYPE definition from the parser file.
Thus defaulting to int and having yystate accidentally overwritten on updating
yylval. A difficult bug.
On 21 Jul 2010, at 00:03, Paul Hilfinger wrote:
The Bison documentation says that due to technical differences
between C
and C++, a C++ compiler wouldn't be able to compile or properly
execute
(not clear which) a Bison C program that tried to grow the parser
stack. What exactly is this
On 23 Jul 2010, at 00:58, Paul Hilfinger wrote:
BTW: I observe that ISO C++ has a template function
std::uninitialized_copy, defined in memory, which ought to work
for
copying a stack properly.
The algorithm is
for (; first != last; ++result, ++first)
new
On 23 Jul 2010, at 00:00, Paul Hilfinger wrote:
One problem is that the C stack does not call C++ copy constructors
when reallocating. So one can only use a POD semantic value.
I was indeed aware of the non-POD issue. However, this problem
already
prevents the use of %union in C++ files if
