Re: Extension compatibility policy

["E. Weddington" <ericw at evcohs dot com>]

Paul Schlie wrote:

> After having the chance to experiment a little, it would seem most ideal in
> the short term to enable GCC to add an explicit target specific attribute to
> the effective implied __FUNCTION__ declaration; in AVR's case for example:
>
>  #define ROM __attribute__((__progmem__)) /* an avr attribute */
>  
This is unnecessary as you should already know; avr-libc already 
#defines PROGMEM as the attribute specified above.

>  something (ROM __FUNCTION__);
>
> Thereby effectively implying the local declaration/use of __FUNCTION__ as:
>
>  ROM static const char __FUNCTION__[4] = "foo";
>  something (__FUNCTION__);
>
> Which would enable the backward compatible addition of target specific
> attributes to the implied declaration of __FUNCTION__, enabling avr's
> backend to place it in progmem, and be explicitly accessed using PSTR()
> macros.
>  

You're lost. You really don't know what the PSTR() macro does in 
avr-libc, do you?


> (Although I know there's concern about enabling fine grain specification
> of attributes for implied static const initializer objects; but now believe
> that both both fine grain as well as having the ability to define a target
> specific attribute in bulk for all implied static const initializer objects
> as may be most appropriate in different circumstances
>  
No, Joseph Myers already told you that overloading "static const" as 
defining the attribute for objects in different address spaces is NOT 
the way to do it. There should not be an implied way of doing this that 
overloads C keywords. It should be explicit.


This issue has already been talked to death. But, hey, everybody is 
waiting for a patch from you, Paul.

Eric