#if behavior on not #defined

General discussion on mikroC PRO for dsPIC30/33 and PIC24.
Post Reply
Author
Message
steve42lawson
Posts: 183
Joined: 06 Mar 2008 17:35
Location: St. George, UT
Contact:

#if behavior on not #defined

#1 Post by steve42lawson » 10 Oct 2020 00:22

The C99 standard specifies at §6.10.1 ¶3:

After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers are replaced with the pp-number 0

Does the Mikro C compiler adhere to this. For example:

Code: Select all

void main()
{
#if NOT_DEFINED
  // Some Code
#endif
}
How will the compiler handle this? Is it treated the same was as the following:

Code: Select all

void main()
{
#ifdef NOT_DEFINED
  #if NOT_DEFINED
    // Some Code
  #endif
#endif
}
I could find no mention of this in the documentation.
?
Humility is the lack of the desire to impress, not the lack of being impressive.

hexreader
Posts: 1784
Joined: 27 Jun 2010 12:07
Location: England

Re: #if behavior on not #defined

#2 Post by hexreader » 10 Oct 2020 01:02

Disclaimer: I know almost nothing, but...

Trying simple code and checking the assembly file that results leads me to the following (possibly wrong) conclusions.

#if help states use as:
#if constant_expression_1
<section_1>

[#elif constant_expression_2
<section_2>]
...
[#elif constant_expression_n
<section_n>]

[#else
<final_section>]

#endif
Seems to me that NOT_DEFINED is not an expression that can evaluate to true or false. What would the value of something that is not defined be?
Trial code seems to suggest that the
#if statement will treat NOT_DEFINED as if it was zero - so the code that follows will not be compiled.

I sense that using #if NOT_DEFINED is not a valid thing to do anyway. Seems to work on this compiler, but maybe by accident rather than design.

Even if it is a valid thing to do, I cannot think what it gains you over #ifdef anyway - except maybe a tiny bit of typing saved.

..... but I am no expert ..... happy to be corrected - EDIT - ignore red text - I corrected myself already :(
Last edited by hexreader on 10 Oct 2020 01:21, edited 1 time in total.
Start every day with a smile...... (get it over with) :)

hexreader
Posts: 1784
Joined: 27 Jun 2010 12:07
Location: England

Re: #if behavior on not #defined

#3 Post by hexreader » 10 Oct 2020 01:12

Doh ! :oops:

Why didn't I read just a little further down the help text :(
The #ifdef and #ifndef directives can be used anywhere #if can be used and they can test whether an identifier is currently defined or not. The line

#ifdef identifier
has exactly the same effect as #if 1 if identifier is currently defined, and the same effect as #if 0 if identifier is currently undefined. The other directive, #ifndef, tests true for the “not-defined” condition, producing the opposite results.

The syntax thereafter follows that of #if, #elif, #else, and #endif.

An identifier defined as NULL is considered to be defined.
I think this answers the question
Start every day with a smile...... (get it over with) :)

steve42lawson
Posts: 183
Joined: 06 Mar 2008 17:35
Location: St. George, UT
Contact:

Re: #if behavior on not #defined

#4 Post by steve42lawson » 11 Oct 2020 00:48

hexreader wrote:
10 Oct 2020 01:12
The #ifdef and #ifndef directives can be used anywhere #if can be used and they can test whether an identifier is currently defined or not. The line

#ifdef identifier
has exactly the same effect as #if 1 if identifier is currently defined, and the same effect as #if 0 if identifier is currently undefined. The other directive, #ifndef, tests true for the “not-defined” condition, producing the opposite results.

The syntax thereafter follows that of #if, #elif, #else, and #endif.

An identifier defined as NULL is considered to be defined.
I think this answers the question

Yeah, I saw that [and read it :wink: ]. The reason why I don't think it answers the question is it doesn't treat the case where #if is used on an identifier that was not EVER defined. I want to know if the compiler writer(s) took this case into consideration, and handled it. I need to know if I can expect well-defined behavior, or will code like this fall into the Twilight Zone of undefined behavior.

Yes, #ifdef does this, and yes #ifdef has the same effect as #if 0, if the identifier is currently undefined, BUT that says NOTHING about what happens if I use #if on an identifier that is currently not defined. Is it treated like #if 0? THAT's the thing I want to verify. And I need definitive verification, because this code is going into a product.

Otherwise, I'm going to have to do every dang code selection like this:

Code: Select all

void main()
{
    #ifdef NOT_DEFINED
      #if NOT_DEFINED
        // Some elective code
      #endif
    #endif
}
And, yeah, I know a better solution would probably be to use header files to select code for different hardware options, but the Mikroe IDE doesn't seem to be able to follow logic into included header files! Like, for instance if I want to use the IDE to navigate to a function defined in one of the header files.
Humility is the lack of the desire to impress, not the lack of being impressive.

hexreader
Posts: 1784
Joined: 27 Jun 2010 12:07
Location: England

Re: #if behavior on not #defined

#5 Post by hexreader » 11 Oct 2020 00:59

Yes, I think I see what you mean now....

The wording is not 100% clear and allows for ambiguity.

I read help text as #if NON_DEFINED will produce no code if NON_DEFINED is undefined, but it does not quite say that clearly.

Hopefully ME support staff will see this post on Monday when they get back to work, but if not, then I suggest raising a support ticket.

The documenting error is subtle, but I (now) agree that the help text is ambiguous.
Start every day with a smile...... (get it over with) :)

Post Reply

Return to “mikroC PRO for dsPIC30/33 and PIC24 General”