[antlr-interest] [C Runtime] Redefinition issue in antlr3convertutf.h

[Gonzague Reydet]

Jim,

Thanks for your reply!

Actually I encounter this issue in code that calls the parser by including
the generated header files.
I agree with you that those values should not be defined elsewhere. But
they are in some piece of old legacy code that can't be changed easily.
IMO such generic naming should never be used without a more descriptive
prefix to avoid such conflicts.
I still don't understand why they are defined in the ANTLR public API. If
they are needed by ANTLR sources, why not defining them in an internal
ANTLR header that will not be published when installing the library? I
don't see any reason for using those generic definitions from the ANTLR API
point of view, we could easily use the ANTLR3_TRUE and ANTLR3_FALSE
definitions instead.

Moreover I encountered other warnings using an old version of GCC compiling
my code that include the system string.h file and the generated parser
headers. GCC complained about shadowed redefinition of the string.h index()
function by some of the ANTLR function pointer parameters like
"void (*setStartIndex) (struct ANTLR3_COMMON_TOKEN_struct * token,
ANTLR3_MARKER index);" in antlr3commontoken.h. Note that I don't get those
warnings using a newer version of GCC on a more recent system. Is there a
minimal version of GCC supported to use ANTLR C runtime?

Some other unrelated questions:
- Why is the ANTLR3 C runtime archive root folder labelled as "beta4"?
- Why does the ANTLR C API documentation have not been regenerated since
the runtime version 3.4 release?

Thanks for the help
Gonzague

2011/11/21 Jim Idle <jimi at temporal-wave.com>

> It is more likely that you need to reorder your includes as some other
> non-antlr header has defined true and false.
>
> It is not likely that those interfering headers have used the same types
> and so on, even though it is likely that they end up being the same values
> in the end (assuming you are not trying to compile the runtime as C++).
> But if I just use whatever you give me, it could generate strange errors
> that are harder to resolve. Also, if I undef them in the header, I can't
> predict what I have done to your other code. Hence, it is better to leave
> it; though I think that there is an argument not to use such obvious names
> in the library code (but I reused the standard Unicode.org supplied code).
>
> If you read through the API docs, you will see that there are various
> @directives that you can use to influence the order of includes. You can
> also look at the examples, which talk about this and how to relocate code
> outside the space so you don't get these interferences.
>
> Finally, this possibly indicates a more fundamental issue if you are
> trying to embed code that refers to things outside ANTLR, within grammar
> actions. Ideally you just call external helper methods that know how to
> talk to your other components. If however you are just including antlr.h
> in files outside the grammar, then you should just include antlr first, or
> undef the definitions after including the other headers, assuming that you
> do not use them after that.
>
> Jim
>
> > -----Original Message-----
> > From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> > bounces at antlr.org] On Behalf Of Gonzague Reydet
> > Sent: Sunday, November 20, 2011 11:29 PM
> > To: antlr-interest at antlr.org
> > Subject: [antlr-interest] [C Runtime] Redefinition issue in
> > antlr3convertutf.h
> >
> > Hi all,
> >
> > Using the ANLTR C runtime v3.4, I encounter a redefinition error of
> > "false"
> > and "true" values in antlr3convertutf.h at compile time when including
> > the antlr3.h file in my code.
> >
> > IMO we should have a verification to check if those flags are already
> > defined or not before defining them in the antlr3convertutf.h file.
> > Something like the following code should fix my compiling issue :
> >
> > #ifndef    true
> > #define true ANTLR3_TRUE
> > #endif
> >
> > #ifndef    false
> > #define false ANTLR3_FALSE
> > #endif
> >
> > Is there any reason for not doing this check here? Is this a known
> > issue?
> > Moreover I not sure this is the right place to define such generic
> > flags...
> > Why do you need to define them here?
> >
> > Regards,
> > Gonzague
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> > email-address
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>



-- 
Tél : +33 (0)6 21 02 90 48