[antlr-interest] Jim Idle: C-Runtime and C++Builder, E2342 Type mismatch in parameter

Udo Weik WeikEngOff at aol.com
Wed Oct 5 03:28:31 PDT 2011


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<jimi at temporal-wave.com>:
>
>> 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: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>>> bounces at antlr.org] On Behalf Of Udo Weik
>>> Sent: Tuesday, October 04, 2011 2:23 PM
>>> To: antlr-interest at antlr.org
>>> 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: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>>>>> bounces at antlr.org] 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: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>>>>>>> bounces at antlr.org] 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_definition730)
>>>>>>> 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: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>>>>>>>>> bounces at antlr.org] 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-address
>>
>
>
>
> ----------------------------------------------------------------
> 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



More information about the antlr-interest mailing list