Extension compatibility policy

[Bernardo Innocenti]

Giovanni Bajo wrote:
> Mike Hearn <mike@navi.cx> wrote:

> In your __FUNCTION__ case, we are basically in the latter group. __FUNCTION__
> is a well-documented extension in C90 (it's part of C99 in some form now), and
> it was never documented to be a macro. The fact that was named like a macro and
> worked like a macro for years is indeed unfortunate. Notwithstanding that, GCC
> maintainers acknowledged its widespread use and the bug of it working like a
> macro was deprecated for around 3 years. We cannot do more than that.

For the record, I've recently faced an unsolvable problem
due to __FUNCTION__ now working as a variable definition.

In an embedded AVR application, I use a macro like this
for debugging purposes:

  #define TRACEMSG(msg,...) __tracemsg(__func__, msg, ## __VA_ARGS__)


This causes __func__ to be allocated in the data section,
thus wasting lots of precious data memory.

To move strings into program memory, there's a macro like this:

 #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })


But this wouldn't work because __func__ does not work like
a string literal:

 #define TRACEMSG(msg,...) __tracemsg(PSTR(__func__), msg, ## __VA_ARGS__)

C99's __func__ is supposed to work as if a "const char __func__[]".
The __FUNCTION__ extension could instead be made to work like a
string literal.   We could live without string pasting capabilities
if it helps keeping the interface between cpp and the C frontend
cleaner.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/