This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extension compatibility policy
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Bernardo Innocenti <bernie at develer dot com>
- Cc: Giovanni Bajo <giovannibajo at libero dot it>, Mike Hearn <mike at navi dot cx>, gcc at gcc dot gnu dot org
- Date: Wed, 2 Mar 2005 00:22:25 +0000 (UTC)
- Subject: Re: Extension compatibility policy
- References: <pan.2005.02.26.19.57.52.648712@navi.cx> <039001c51d89$8e9b3ab0$d4b02997@bagio><42250329.6060809@develer.com>
On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
> 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.
How about calling decl_attributes from fname_decl so a target
insert_attributes hook can add attributes to __func__? Would that suffice
to solve your problem?
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)