Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal

[Georg-Johann Lay]

Jan Waclawek schrieb:
> > IMO such macros are bad style, there is no reason for them.
>
> I already said what is the reasons for them, here:
> https://savannah.nongnu.org/bugs/?33716 and here
> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=871000#871000
> . And I repeat, it is a feature for the users, and a continuity plan.
>
> > Style is, of course, matter of taste.
> >
> > Try #define PROGMEM __attribute__((progmem)) #define prog_char char
> > PROGMEM prog_char * p = 0;
>
> Yes, I see, a poor style indeed not to use NULL to assign a null
> pointer ;-)

prog_char as a macro is dreaded.

const prog_char * const p = NULL;

puts p in progmem so it's broken by design. With that users will be 
taken for a ride.

> I am aware of this "problem" (warning about progmem attribute being

So if you are aware of problems why do you propose to put it in avr-libc?

> ignored, harmless but annoying). <avr/pgmspace.h> already contains a
> macro PGM_P to be used as a pointer to a progmem char, and in the
> proposed  pgmspace.h in

PGM_P does not cure the line above which *would* work with names 
address. So you are killing your own "continuity plan".

> > @Jan:
> >
> > That's the reason why a always said that progmem is something 
> > com-ple-tly different to a named address. Now you see why.
>
>
> Do I look that stupid? I know progmem was a kludge; and the remark in
> your previous post clearly indicates that it was originally
> intentionally intended to work also with the typedefs (i.e. as a

The comment just says it's not a good thing to do and only for 
compatibility issues for 3.0.  Presumably of some users that idn't want 
to keep their source clean.

> Deprecating the typedefs in progmem will force them to manually
> rewrite their codebase, and introduction of the named spaces would

They sould have done this since years already.

> force them to rewrite them again (if they want to benefit from the
> better resulting code). I wouldn't call that a nice step towards the

I don't think named addresses will result in better code, it's more 
likely that you will see code inferior to inline assembly aka. pgm_ macros.

Named addresses are helpful to write clean, type-safe source without 
relying on non-standard extensions. And it will make is easier to port 
code from AVR th other architectures. That's all.

Don't expect good code quality from named addresses.

> Jan