Topic : RKit-STM8 V 2.14.0901 Incorrect C Preprocessor Token Concatenation

Forum : ST7/STM8

Original Post
Post Information Post
March 16, 2009 - 11:24pm
Guest

When I compile this small program:

******BEGIN*****
at 0x500a hreg PC_ODR ;

#define BIT6 (0x40)

#define LED_GRN BIT6
#define LED_GRNOUT PC_ODR

#define gpioSetOutput( pin ) pin ## OUT |= pin

void test (void)
{
gpioSetOutput(LED_GRN);

}
*****END******

I get the following preprocessor file:

*****BEGIN*****
at 0x500a hreg PC_ODR ;
void test ( void ) {
( 0x40 ) #OUT |= ( 0x40 ) ;
}
******END******

What I expected was the preprocessor to generate the line:
PC_ODR |= ( 0x40 );

Which is what I get with other ANSI C compilers I have tried.

Is there some way to get this to work the way I need it to? I have a lot of Macros similar to this that have the same problem.

Replies
Post Information Post
+1
0
-1
March 17, 2009 - 10:55am
Raisonance Support Team

Hello,

Thanks for your detailed report.
We have been looking at the problem and ackowledge the fact that our preprocessor has a problem.
The "6.8.3.1 Argument substitution" chapter of the C standard is not correctly implemented, as stated:
"A parameter in the replacement list, unless preceded by a # or ## preprocessing token or followed by a ## preprocessing token, is replaced by the corresponding argument after all macros contained therein have been expanded."

In our case, the preprocessor substitutes the arguments even if a ## token follows the macro parameter.

We are currently working on a fix if our compiler. A release candidate was in the starting blocks, so we have to revalidate the compiler with this fix, hence the released compiler should be available by the end of the month.

There is a workaround however: The problem only appears if the parameter is BEFORE the ##, not if it follows it.
So you could write:

at 0x500a hreg PC_ODR ;

#define BIT6  (0x40)

#define LED_GRN             BIT6
#define OUTLED_GRN          PC_ODR          // Inverted args

#define gpioSetOutput( pin )      OUT ## pin |= pin     // Inverted again

void test (void)
{
  gpioSetOutput(LED_GRN);

}

That should fix the problem enough so that you can wait for the next release of the compiler.

Best regards,
Bruno

+1
0
-1
March 17, 2009 - 7:59pm
Guest

Thanks, Bruno

That workaround works for me.

Now if I go one step farther I run into another issue. Try to compile this:

at 0x500a hreg PC_ODR ;

#define BIT5 (0x20)
#define BIT6 (0x40)

#define LED_RED BIT5
#define OUTLED_RED PC_ODR
#define LED_GRN BIT6
#define OUTLED_GRN PC_ODR

#define gpioSetOutput( pin ) OUT ## pin |= pin

#define LED_AMB_ON() { gpioSetOutput(LED_RED); gpioSetOutput(LED_GRN); }

void test (void)
{
LED_AMB_ON();
}

+1
0
-1
March 18, 2009 - 10:52am
Raisonance Support Team

Hi,

We reproduced your problem in our labs.
Althgough yesterdays' issue is now fixed and will appear in the next Compiler release, we will not have time to fix the second one until then.

The two problems have been entered into our bugs base and acknowledged.

If you are interested, we can send you a patch for it as soon as available.

Regards,
Bruno