enums have no real advantage in C, only C++ Jim
> -----Original Message----- > From: [email protected] [mailto:antlr-interest- > [email protected]] On Behalf Of Udo Weik > Sent: Wednesday, October 05, 2011 3:29 AM > To: Ivan Brezina; Antlr-Interest Antlr.Org > Subject: Re: [antlr-interest] Jim Idle: C-Runtime and C++Builder, E2342 > Type mismatch in parameter > > Hello Ivan, > > > as this issue is quite common and is not easy to detect. > > Could it be possible that in the new ANTLR release will be those > > #defines replaced with some kind of enum? > > thanks for your support. It wasn't my grammar, so problems like this > and a overall problematic target-IDE complicate such problems > additionally. > enums are of course much better to debug, my suggestion was to add > user-defined prefixes where appropriate (token names/ now #defines, > lexer rules/now function names with 'm' as prefix when I remember > correcty and parser rules/now function names without prefix (had a > problem here, too: int). > And my opinion is that a grammar is a grammar, I can't track for every > target language whether a token/rule is a reserved word or not. > > Many thanks and greetings > Udo > > > > Quoting Jim Idle<[email protected]>: > > > >> This is a problem with your grammar (see lots of previous posts) - > >> you have a token that you have called NULL and you cannot name > tokens > >> with the same name as reserved words. Instead of: > >> > >> NULL : 'null'; > >> > >> I just use > >> > >> KNULL : 'null' ; > >> > >> Using the K to stand for keyword, but anything will do. > >> > >> > >> Jim > >> > >>> -----Original Message----- > >>> From: [email protected] [mailto:antlr-interest- > >>> [email protected]] On Behalf Of Udo Weik > >>> Sent: Tuesday, October 04, 2011 2:23 PM > >>> To: [email protected] > >>> Subject: Re: [antlr-interest] Jim Idle: C-Runtime and C++Builder, > >>> E2342 Type mismatch in parameter > >>> > >>> Hello Jim, > >>> > >>>> Find the #define of the macro in your source code, see if there is > >>>> anything else in there that is further expanded, such say NULL or > >>> free > >>>> etc. > >>> > >>> grepping the result of the prepocessor macro expansion showed that > >>> NULL is always 99. The reason is NULL in the tokens { ... }-section > >>> in the grammar. That token gets the value 99 assigned: > >>> #define NULL 99 > >>> Is there any way to fix that in the C-Runtime directly without > >>> changing the grammar? > >>> > >>> Many thanks and greetings > >>> Udo > >>> > >>> > >>>>> -----Original Message----- > >>>>> From: [email protected] [mailto:antlr-interest- > >>>>> [email protected]] On Behalf Of Udo Weik > >>>>> Sent: Tuesday, October 04, 2011 10:20 AM > >>>>> To: Antlr-Interest Antlr.Org > >>>>> Subject: Re: [antlr-interest] Jim Idle: C-Runtime and C++Builder, > >>>>> E2342 Type mismatch in parameter > >>>>> > >>>>> Hello Jim, > >>>>> > >>>>> thanks for your fast anser. > >>>>> > >>>>>> It sounds more to me like there is something in the pre- > processor > >>>>> that > >>>>>> has redefined whatever should really be there. You should trace > >>>>>> through the actual #defines to find out what. > >>>>> > >>>>> And what "should really be there"? Can you give me an example of > >>>>> an correct call (expanded) to ->push( ... )? > >>>>> > >>>>> Many thanks and greetings > >>>>> Udo > >>>>> > >>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: [email protected] [mailto:antlr-interest- > >>>>>>> [email protected]] On Behalf Of Udo Weik > >>>>>>> Sent: Tuesday, October 04, 2011 10:05 AM > >>>>>>> To: Antlr-Interest Antlr.Org > >>>>>>> Subject: Re: [antlr-interest] Jim Idle: C-Runtime and > >>>>>>> C++Builder, > >>>>>>> E2342 Type mismatch in parameter > >>>>>>> > >>>>>>> Hello Jim, > >>>>>>> > >>>>>>> I was able by using the prepocessor macro expansion to find at > >>>>>>> least the location of the problem > >>>>>>> > >>>>>>> > FOLLOWPUSH(FOLLOW_subtype_indication_in_access_type_definition73 > >>>>>>> 0) > >>>>>>> which expands to > >>>>>>> ctx->pParser->rec->state->following->push( > >>>>>>> ctx->pParser->rec->state- > >>>>>>>> following, > >>>>>>> ((void > >>>>>>> *)(&(FOLLOW_subtype_indication_in_access_type_definition730))), > >>>>>>> 99 ) ; The > >>>>>>> problem is the value 99, which should be of type > >>>>>>> void (ANTLR3_CDECL *freeptr)(void *)) according to > >>>>>>> antlr3collections.h, line 211: > >>>>>>> /* > >>>>>>> ANTLR3_STACK_struct Struct Reference > >>>>>>> > >>>>>>> 00199 typedef struct ANTLR3_STACK_struct > >>>>>>> 00200 { > >>>>>>> 00203 pANTLR3_VECTOR vector; > >>>>>>> 00204 > >>>>>>> 00207 void * top; > >>>>>>> 00208 void (*free) (struct > >>>>>>> ANTLR3_STACK_struct * stack); > >>>>>>> 00209 void * (*pop) (struct > >>>>>>> ANTLR3_STACK_struct * stack); > >>>>>>> 00210 void * (*get) (struct > >>>>>>> ANTLR3_STACK_struct * stack, ANTLR3_INTKEY key); > >>>>>>> 00211 ANTLR3_BOOLEAN (*push) (struct > ANTLR3_STACK_struct > >>> * > >>>>>>> stack, void * element, void (ANTLR3_CDECL *freeptr)(void *)); > >>>>>>> 00212 ANTLR3_UINT32 (*size) (struct > ANTLR3_STACK_struct > >>> * > >>>>>>> stack); > >>>>>>> 00213 void * (*peek) (struct > >>>>>>> ANTLR3_STACK_struct * stack); > >>>>>>> 00214 > >>>>>>> 00215 } > >>>>>>> 00216 ANTLR3_STACK; > >>>>>>> */ > >>>>>>> > >>>>>>> Can you be so kind and explain me the purpose of 99 (and why is > >>>>>>> it just an > >>>>>>> int) and whether there is a more or less corresponding > >>>>> functionallity > >>>>>>> for the ANTLR3_STACK_struct in ANTLR (Java sources). > >>>>>>> > >>>>>>> Many thanks and greetings > >>>>>>> Udo > >>>>>>> > >>>>>>> > >>>>>>>> I don't really know what you are trying to do or what compiler > >>> you > >>>>>>> are > >>>>>>>> using etc, but remember this is C code not C++ code so if you > >>> turn > >>>>>>>> on all the warnings in the C++ compiler then you may get the > >>>>>>>> odd > >>>>>>> warning. > >>>>>>>> But without seeing all the code, I can't guess where that > >>>>>>>> warning > >>>>> is. > >>>>>>>> It isn't the FOLLOWPUSH macro though. It looks more likely > that > >>>>>>>> you are not including the correct headers and so the prototype > >>>>>>>> is > >>>>>>> defaulting to int. > >>>>>>>> > >>>>>>>> As for tabs vs space... well it is generated code. You could > >>>>>>>> always untab it using any one of a thousand tools, or modify > >>>>>>>> the code generation template and remake ANTLR. > >>>>>>>> > >>>>>>>> I don't know anything about C__ builder, but it seems to be > >>>>>>>> more of a hindrance than a help? > >>>>>>>> > >>>>>>>> Jim > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: [email protected] [mailto:antlr- > interest- > >>>>>>>>> [email protected]] On Behalf Of Udo Weik > >>>>>>>>> Sent: Saturday, October 01, 2011 12:22 AM > >>>>>>>>> To: Antlr-Interest Antlr.Org > >>>>>>>>> Subject: [antlr-interest] Jim Idle: C-Runtime and C++Builder, > >>>>> E2342 > >>>>>>>>> Type mismatch in parameter > >>>>>>>>> > >>>>>>>>> Hello Jim, > >>>>>>>>> > >>>>>>>>> I'm getting some > >>>>>>>>> E2342 Type mismatch in parameter 'freeptr' (wanted > >>>>>>>>> 'void > >>>>>>> (*)(void > >>>>>>>>> *)', got 'int') errors in code lines like > >>>>>>>>> > >>>>>>>>> > >>> FOLLOWPUSH(FOLLOW_subtype_indication_in_access_type_definition730 > >>>>>>>>> ) > >>>>>>>>> ); Any hint? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> And in the following functions an analog problem > >>>>>>>>> E2342 Type mismatch in parameter 'state' (wanted > >>>>>>>>> 'ANTLR3_RECOGNIZER_SHARED_STATE_struct *', got 'int')I I just > >>>>>>>>> declared state and initialized it with NULL: > >>>>>>>>> > >>>>>>>>> ANTLR3_API pXYZLexer XYZLexerNew( pANTLR3_INPUT_STREAM > >>>>>>>>> instream > >>> ) > >>>>> { > >>>>>>>>> pANTLR3_RECOGNIZER_SHARED_STATE state ; // UW > >>>>>>>>> state = NULL ; // UW > >>>>>>>>> > >>>>>>>>> // See if we can create a new lexer with the standard > >>>>>>> constructor > >>>>>>>>> // > >>>>>>>>> // UW return XYZLexerNewSSD(instream, NULL); > >>>>>>>>> return XYZLexerNewSSD(instream, state); // UW } > >>>>>>>>> > >>>>>>>>> Same problem with > >>>>>>>>> ANTLR3_API pXYZParser XYZParserNew( > >>>>>>>>> pANTLR3_COMMON_TOKEN_STREAM instream ) { > >>>>>>>>> pANTLR3_RECOGNIZER_SHARED_STATE state ; // UW > >>>>>>>>> state = NULL ; // UW > >>>>>>>>> > >>>>>>>>> // See if we can create a new parser with the standard > >>>>>>> constructor > >>>>>>>>> // > >>>>>>>>> // UW return XYZParserNewSSD(instream, NULL); > >>>>>>>>> return XYZParserNewSSD(instream, state); // UW } > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Is it in any way possible to avoid tabs in the generated > code? > >>>>>>>>> I would prefer two spaces for one tab. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Many thanks and greetings > >>>>>>>>> Udo > >>>>>>>>> > >>>>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>>> 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 > >>>>> > >>>>> > >>>>> 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 > >>> > >>> > >>> 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- > addres > >> s > >> > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > > 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 List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
