[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
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
- [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, (continued)
- [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Jan Waclawek, 2011/09/26
- Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Weddington, Eric, 2011/09/26
- Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Bill Westfield, 2011/09/27
- Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Georg-Johann Lay, 2011/09/27
- Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Jan Waclawek, 2011/09/27
- Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal,
Georg-Johann Lay <=
Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Georg-Johann Lay, 2011/09/27
Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal, Georg-Johann Lay, 2011/09/28