[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: Jan Waclawek
Subject: Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
Date: Tue, 27 Sep 2011 22:05:33 +0200

> 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 ;-)

I am aware of this "problem" (warning about progmem attribute being 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 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=112241 I 
simply dropped the progmem attribute for that macro. That is what the user is 
forced to do "manually" anyway; preparing a macro for them will provide a path 
to future seamless change to properly qualified pointers.

> @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 decent memory class qualifier a.k.a. 
named address designator or whatever should). And then apparently the 
implementation fell behind the intention up to a point where you found it 
broken, and nobody is now willing to fix it. So the best what can be done for 
the users is to come up with a decent continuity plan. 

Deprecating the typedefs in progmem will force them to manually rewrite their 
codebase, and introduction of the named spaces would 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 users.


reply via email to

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