__FUNCTION__ definition changed radically between 8.1 and 8.5 ?

[dummy_decoy]

i'm just noticing it now, but all my code that used __FUNCTION__ do not compile anymore.

it seems the definition of __FUNCTION__ have been quite broken between 8.1 and 8.5:
- we now have to use a specific pragma (iso_9899_1999) to use this identifier that we had not to use previously. existing code that used this feature has to be changed.
  (by the way, this pragma is not mentionned in the documentation. is my documentation broken ?)
- __FUNCTION__ was previously a macro, so it could be concatenated to a string, this way:
 printf( "i am talking from function " __FUNCTION__ " and it works" ).
  Now, it seems it is declared as a const char, so the use above is prohibited.
- also, since __FUNCTION__ is something like a special identifier, it cannot be undefined in any case nor can it be redefined, regardless of the use of the aforementioned pragma.

now that i switched to 8.5, i have to rewrite big parts of my applications to be able to compile it again.

i do appreciate the effort made to integrate C99 features into CVI, but this change is radically not backward compatible and breaks a lot of existing code. so, is there a way to get the old behavior when not using the C99 pragma ?

[dummy_decoy]

a little addendum:
using CVI 8.5, and no #pragma iso_9899_1999, if you inadvertently write this:

#define __func__ __FUNCTION__

the compiler will block indefinitely in what seems to be an infinite loop...

[Mert_A.]

There's another thread that discusses this, but basically, the implementation was changed (from macro to global variable, as per the C99 spec for __func__) and disabled except if CVI's new C99 extensions are enabled.  It was not anticipated that many knew about or were using this macro, since it is undocumented.  It turns out that wasn't true, so the original behavior will be restored in the next update to CVI.

Sorry again.

Mert A.
National Instruments


Message Edited by Mert A. on 03-10-2008 11:09 AM

[dummy_decoy]

well, the __FUNCTION__ macro, although undocumented has been available in lots of compilers since a long time: Visual C++, GCC, digitalmars and i'm pretty sure i forget many well known implementation. i've also seen it described many times along with __LINE__, __FILE__, __TIME__, __DATE__, __STDC__ in self-established language reference.

this explains why a lot of people are using this feature. since the official C language reference is not available for free, no-one knows where the truth lies: is it standard or is it not ? i'm pretty sure compilers replicated this macro because one mainstream implementation did it first and people were so much used to it that they kept complaining until it was available.

now about restoring the original behavior: please, i don't want a C99 feature removed. it seems that the C standard calls for a __func__ identifier declared as a const char *. would it be possible to have the real __func__ available for those using the C99 pragma, and __FUNCTION__ defined as a macro for those that don't use it ? this would not break old code, and still allow for a smooth transition to C99 for those who knows what they are doing. i know that maintaining 2 different implementations of the same feature is cumbersome, but it definitely needs some thinking.

also, be aware that i will always support standard compliance, even if it means rewriting my code without __FUNCTION__. my original post was only because i was surprised of the change in declaration. (if only i could have the official C standard as a strong reference...)

(still the infinite loop in the preprocessor is surprising)

[Mert_A.]

I apologize for the brevity of my earlier response.  In fact, what you describe is what will be done in the next update.  The pre-8.5 (macro) implementation of __FUNCTION__ will be available in any program.  Additionally, if compiling with C99 extensions enabled, __func__ will be defined as a global string variable.

Also, the infinite loop issue will be fixed as well, though it's probably not something anyone should run into so long as __FUNCTION__ and __func__ are properly available.

Mert A.
National Instruments

[dummy_decoy]

thanks for the clarification.
this is perfect !