[antlr-interest] Problem with C target output on example C grammar

Kamil Burzynski nopik at data.pl
Tue Apr 1 22:55:16 PDT 2008


Hello,

>> evaluate returns [result]: r = expression { result = r; };
>>
>> (this is python syntax, though the usage of 'returns' keyword should
>> stay the same). The problem is that C target when sees something like
>> "r
>> = expression"

> No, that isn't your problem, look at the generated code.

Indeed.

>> does initialize internal variable with NULL before
>> assignment. This is improper even in plain C.

> I am well aware of what can be initialized with what in C :-).

Yes, I know. You misunderstood me - as I was not implying that you do
not know C. I wanted to tell, that such approach can fail even in C, you
do not need C++ to make it fail.

> Please consider that you may be doing something wrong or slightly
> unorthodox yourself before blaming the C target ;-)

Well, the thing is that it is natural way of doing in C++. In pure C
returning struct by value is rarely used, I agree. But in C++ (and Java
in fact), returning objects by value is much more common. Especially in
my case - when the object was smart pointer itself. These entities are
*meant* to be passed as value. And since they point to (usually)
non-trivial class, you cannot reduce them away by returning a bunch of
struct members at once.

> Because NULL is the default initializing value when the type is
> unknown. Return anything other than a struct and you will be fine.

Yes, I know that. The example was just to show that there are cases when
= NULL cannot work. I chose struct intentionally to indicate this
problem.

> Now, why are we initializing the return values? I no longer
> remember, but I think that there is some good reason and it might be
> that it is the same code that is used for initializing tree return
> variables. (If you use output=AST then the error actually goes away).

Yeah, I am not familiar enough with antlr yet and do not know what tree
parsing is for, gotta read more about it. Unfortunately I did not found
any good documentation about it on antlr.org, maybe I was not looking
carefully enough.

> I know though that I have looked at this before and there was no easy
> solution adn in fact no NEED for a solution (see below for your
> error). Perhaps it is coming time to revisit it and make sure I have
> documented it at least.

I agree, that there is no easy way for fixing it. Either you leave all
variables uninitialized or initialize all of them somehow, in uniform
way. In Java '= null' was very safe for almost anything, not so in
C/C++. But, lack of solution is actually painful in C++. The
operator=(int) was intentionally removed from boost smart pointers (and
they are very important tool in modern c++ programmer toolbox), as
potentially dangerous. Now, your target forced me to inherit original
pointer class and add this operator=(int) myself. Making whole program
slower, less efficient and more error-prone ;(

> However, the answer to your problem is that the rule already
> returns a struct if you have more than one return value, so if you
> have just one element in your struct, then don't use the struct. If

But if you have object as in Java, you cannot return all its members
separately, that would make no sense.

> So, I think that we have reduced all your problems to the one
> grammar error, one user error, one user misunderstanding and zero
> problems with the C target, so I don't think you need to be concerned
> about the C runtime :-)

Not so easy ;) There is one grammar error indeed. I do not know which
problem you are thinking about my error, but the default initialization
is a problem of C runtime for me. Though I agree, that there is probably
no chance of getting it solved. So, some users (most of them are not hit
by the problem, fortunately) are forced to workaround it creating some
awkward solutions.

In my other email I also indicated other error which are purely related to
C runtime, I think: when rule uses 2 scopes, first of them is not
accessible.

-- 
Best regards from
Kamil Burzynski



More information about the antlr-interest mailing list