[antlr-interest] Bug report; generated C(++) code inappropriately initialises non-primitive return values

[Gary R. Van Sickle]

> From: Richard Thrippleton
> 
> When I have a rule of the form
> 
> "rule returns [std::vector<int> foo]
> ..."
>

Unfortunately, you can't do that.  Under the hood, in the C runtime, rules
return a malloc()'ed struct, so your vector<>'s constructor never gets
called and you end up with a bit of a mess.  The only way to make this work
at the moment is to do something like this:

rule returns [std::vector<int> *foo]
@init
{
	foo = new std::vector<int>;
}

There was talk a week or two ago on the list regarding replacing explicit
calls to malloc() with either a redefineable macro (e.g.
ANTLR_MALLOC_OR_NEW_YOU_DECIDE()), or (my preference) something to the
effect of:

#ifdef __cplusplus
// We're being built as C++.
#define ANTLR_NEW() new ...
#else
/* We're being built as C */
#define ANTLR_NEW() malloc ...
#endif

This would allow what you have above to "just work".  I don't know what if
anything became of it however.
 
> the generated code for that rule will start with
> 
> "std::vector<int> foo = NULL;"
> 

Really, it adds that "= NULL" of its own volition?  That sounds like a bug.
All kinds of C PODs (structs for instance) could be in there, none of which
could be pointers, and that should then fail on C as well as C++.  What
version is this?

> which will (obviously) not compile. I've modified the 
> relevant .stg to prevent it generating initialisation code 
> for return values (declaration only), and not encountered any 
> issues in my grammars thus far.
> 
> Richard

Like I noted above, you will run into problems due to the malloc() vs. new
thing.  At least I did the last time I tried it.

-- 
Gary R. Van Sickle