Giovanni Bajo wrote:
Mike Hearn <[EMAIL PROTECTED]> 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/
