RE: [avr-gcc-list] PSTR macro bug in C++

[Dave Hylands]

Hi Ted,

I don't claim to totally understand the whole progmem thing, but I'm
pretty good with C, so I'll make a couple of comments.

>   #define PSTR(s) ({static char __c[] PROGMEM = (s); &(*__c);})
>   #define PSTR(s) ({static char __c[] PROGMEM = (s); &__c[0];})
>   #define PSTR(s) ({static char __c[] PROGMEM = (s); (PGM_P)__c;})
> 
> The third one seems the most likely to be committed. Any C/C++ gurus
> have anything to say on this before I close out the bug (I've been
> sitting on this for way too long).

PGM_P is #defined to be "const prog_char *" (I'm not sure why it's
#defined rather than typedef'd, but that's another issue).

So it seems to me that this should be changeable to this:

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

And I believe that this should also be equivalent

        #define PSTR(s) ({static const prog_char __c[] = (s); __c;})

Personally, I like to not have casts if I don't need them.
The first 2 variants don't return const pointers, so there is a
fundamental difference between them and the 3rd variant. I'm not
familiar enough with the typical usage to know if returning a const
pointer will introduce any new warnings that weren't there before. I
think that it SHOULD return a const pointer, but I know lots of people
don't use const properly, and since it didn't return a const pointer
before, it could cause some warnings.

For example, I believe that this code would have worked before:

        prog_char *c = PSTR( "Test" );

Where it really should have been written

        const prog_char *c = PSTR( "Test" );

So code that's written the first way will now give a compiler warning if
the PSTR macro is changed to the 3rd variation (or either of the ways I
proposed).

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/