<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Compier checks section under #ifdef UNDEFINED -&amp;gt; error</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/32806/compier-checks-section-under-ifdef-undefined---error</link><description> 
It seems a bug crept in CC ARM, may be not only ARM. Consider next
code: 

 
#ifdef IDENTIFIER
 IDENTIFIER();
#endif
 

 
and build output: 

 
..\..\src\module\module.cpp(344): error: #20: identifier &amp;quot;IDENTIFIER&amp;quot; is undefined
 

 
 
GCC does not have</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/137265?ContentTypeID=1</link><pubDate>Wed, 16 Sep 2015 22:55:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:04440b2a-248d-4646-b485-1cf5258e3d78</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The preprocessor output tends to be a good way to solve lots of
slightly muddy assumptions about what data the tools are actually
operating on. The reason all C/C++ compilers has a &amp;quot;preprocess only&amp;quot;
option is the huge number of &amp;quot;doh&amp;quot; moments when people have spent
hours with a problem and then finally look at the actual
expansion.&lt;/p&gt;

&lt;p&gt;
A compiler tool chain is normally run through a very large code
base of tests as regression testing. This code base is not missing
#define, #ifdef, #if defined, ... constructs.&lt;/p&gt;

&lt;p&gt;
So when something slips through, it&amp;#39;s normally very very special
cases that somehow, somewhere deep down affects a coding assumption
in the code optimizer. Or an incorrect understanding of the syntax
might make the tools do what they shouldn&amp;#39;t - but then these errors
tends to be there from day one. Until someone finally has a test case
and reports back about the failure.&lt;/p&gt;

&lt;p&gt;
The standard #include files shipped with the compiler has lots of
#define constructs, so it would most probably be impossible to build
the MDK-ARM libraries if the preprocessor doesn&amp;#39;t handle #define as
expected.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/129031?ContentTypeID=1</link><pubDate>Wed, 16 Sep 2015 13:19:51 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fbdc85d2-1586-40f0-9c56-8eb77eaadd48</guid><dc:creator>Westonsupermare Pier</dc:creator><description>&lt;p&gt;&lt;p&gt;
This worked fine in uV5.15, perhaps you need to use something more
unique than LED, to ensure it&amp;#39;s not defined someplace else, in an
include, command line or something.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;d be very surprised if it were a compiler/preprocessor bug as it
would break a whole galaxy of stuff.&lt;/p&gt;

&lt;pre&gt;
// Define test - led.cpp

void led_test(void)
{
//#define LED  PA7

#ifdef LED
    led_on(LED);  // no errors here when above define commented
#endif
}
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/120664?ContentTypeID=1</link><pubDate>Wed, 16 Sep 2015 12:13:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2c32c732-42c5-489b-aeed-e340c1cf7846</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Have you tested?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Have &lt;b&gt;you&lt;/b&gt;?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;May be it is only my problem?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Quite certainly it is.&lt;/p&gt;

&lt;p&gt;
And instead of accusing others of playing &amp;quot;word games&amp;quot;, how about
you actually learn what those words mean, and how they might apply to
your problem?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/129030?ContentTypeID=1</link><pubDate>Wed, 16 Sep 2015 10:35:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b27d231d-12a2-4c76-ac10-7f31938cd2cd</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
By the way - you haven&amp;#39;t posted specific version information for
your tool set.&lt;/p&gt;

&lt;p&gt;
Lots of people are using the Keil tools.&lt;/p&gt;

&lt;p&gt;
And lots of people are using conditional compilation.&lt;/p&gt;

&lt;p&gt;
My code would fail badly if the preprocessor didn&amp;#39;t do what it
should - it doesn&amp;#39;t with the versions I&amp;#39;m currently using. But I
seldom jump onto the latest versions until I&amp;#39;m starting a new
product. Existing products normally lives their whole life using the
compiler that was used when the product was on beta testing. All to
make sure that I can rebuild and get a binary-identical copy.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/120662?ContentTypeID=1</link><pubDate>Wed, 16 Sep 2015 10:31:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2b9cf5c5-a4c2-404d-915d-01c4e965a1f4</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Have you ordered the compiler to just preprocess the data and
looked at the output?&lt;/p&gt;

&lt;p&gt;
Post the output from the preprocessor. If the output is wrong,
then it&amp;#39;s time to contact Keil support.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/108438?ContentTypeID=1</link><pubDate>Wed, 16 Sep 2015 10:10:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:818d7f13-6f8a-4dbd-8788-42aa4e8beedf</guid><dc:creator>kyb</dc:creator><description>&lt;p&gt;&lt;p&gt;
You are right about how preprocessor/compiler MUST do. And GCC
gives such output, but not ARM. Have you tested? May be it is only my
problem? Note this problem in .cpp file.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/93557?ContentTypeID=1</link><pubDate>Tue, 15 Sep 2015 14:19:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:680de821-0e3d-42ab-ae56-ef4cce0b33bb</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;pre&gt;
//#define LED  PA7
#ifdef LED
    led_on(LED);  //if 1st string commented, we will get an error &amp;quot;undefined identifier&amp;quot;
#endif
&lt;/pre&gt;

&lt;p&gt;
No - if LED isn&amp;#39;t defined then you will not get any &amp;quot;undefined
identifier&amp;quot; from the compiler, because you will not get inside the
#ifdef/#endif block - the preprocessor will clear away the contents
of that block. So you&amp;#39;ll end up with three very empty lines:&lt;/p&gt;

&lt;pre&gt;



&lt;/pre&gt;

&lt;p&gt;
And with LED defined to PA7, you end up with (assuming PA7 isn&amp;#39;t
also a #define)&lt;/p&gt;

&lt;pre&gt;

    led_on(PA7);   &amp;lt;&amp;lt;&amp;lt;=== the preprocessor expansion of the LED define.

&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/82798?ContentTypeID=1</link><pubDate>Tue, 15 Sep 2015 13:36:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6fce985a-a3a3-40b2-a12a-1bfb7cf569f9</guid><dc:creator>kyb</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;gt; #define IDENTIFIER&lt;br /&gt;
I know write so sometimes. Take a look too may another message, where
IDENTIFIER is function argument.&lt;/p&gt;

&lt;pre&gt;
func(IDENTIFIER)
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/64095?ContentTypeID=1</link><pubDate>Tue, 15 Sep 2015 13:30:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cfd45c39-47ce-48cd-ac95-328cea37c5e2</guid><dc:creator>kyb</dc:creator><description>&lt;p&gt;&lt;p&gt;
In addition&lt;/p&gt;

&lt;pre&gt;
//#define LED  PA7
#ifdef LED
    led_on(LED);  //if 1st string commented, we will get an error &amp;quot;undefined identifier&amp;quot;
#endif
&lt;/pre&gt;

&lt;p&gt;
I have found workaround&lt;/p&gt;

&lt;pre&gt;
#define LED  0 //PA7
#if LED
    led_on(LED);
#endif
&lt;/pre&gt;

&lt;p&gt;
But I would like to have ability to undefine LED at all.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/82799?ContentTypeID=1</link><pubDate>Tue, 15 Sep 2015 13:20:07 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2eaef3d9-8016-4034-9897-8db3cc96c910</guid><dc:creator>kyb</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Do you have any idea about the difference between the compiler
and the preprocessor?&lt;/i&gt;&lt;br /&gt;
Ok, it&amp;#39;s supposed &lt;b&gt;toolchain&lt;/b&gt;. You play with words. For end
customer|programmer|me this doesn&amp;#39;t metter.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/69362?ContentTypeID=1</link><pubDate>Tue, 15 Sep 2015 13:02:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:452d456a-e411-4a6c-83b6-f2e06976b7c4</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
If you had written:&lt;/p&gt;

&lt;pre&gt;
#define IDENTIFIER charlie

#ifdef IDENTIFIER
    IDENTIFIER()
#endif
&lt;/pre&gt;

&lt;p&gt;
Then IDENTIFIER would have been defined and you would have ended
up with:&lt;/p&gt;

&lt;pre&gt;
    charlie()
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
And the compiler - and later linker - would have to figure out if any
function named &amp;quot;charlie&amp;quot; exists.&lt;/p&gt;

&lt;p&gt;
But I don&amp;#39;t think your code contains any:&lt;/p&gt;

&lt;pre&gt;
#define IDENTIFIER charlie
&lt;/pre&gt;

&lt;p&gt;
So what would happen if IDENTIFIER would expand to something else?
Remember that you might even go all the way and have:&lt;/p&gt;

&lt;pre&gt;
#define IDENTIFIER
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
where you haven&amp;#39;t given IDENTIFIER any specific value to expand to.
This is also covered by the standard.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Compier checks section under #ifdef UNDEFINED -&gt; error</title><link>https://community.arm.com/thread/64092?ContentTypeID=1</link><pubDate>Tue, 15 Sep 2015 12:42:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:06af26e4-2441-4c2c-b88e-3ad6ec82e923</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;It seems a bug crept in CC ARM&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Nonsense.&lt;/p&gt;

&lt;p&gt;
Do you have &lt;b&gt;any&lt;/b&gt; idea about the difference between the
compiler and the preprocessor?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>