[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Georg-Johann Lay
Subject: Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
Date: Tue, 27 Sep 2011 22:47:43 +0200
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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
. 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".


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]