[Top][All Lists]

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

Re: [avr-gcc-list] prog_mem limitation?

From: Dave N6NZ
Subject: Re: [avr-gcc-list] prog_mem limitation?
Date: Tue, 13 May 2008 09:45:28 -0700
User-agent: Thunderbird 1.5 (X11/20051201)

Marc Wetzel wrote:

Is this the intended behaviour?
What cause is here the trigger?
I'm not eaxctly sure why they behave differently, but the
latter causes teststring[] to be allocated in the .data
section instead of .progmem.

Probably because the second case does not have the 'static' keyword?

Thank you all for your quick answers. I get it now, but if you ask me: I don't like it. I always saw the prog_mem keyword just like a "flash" modifier, don't know from where I got it (IAR maybe?).

Who would need the differentiation of   "static flash" and "flash" ;-)
But I will never forget again.

To me, locally allocated non-static flash is the nonsensical concept. A locally allocated variable is by nature not permanent, unless static.

Of course, since PROGMEM is only a code section attribute, the compiler has no simple way of making semantic checks of that nature. A warning or error would be nice, but I imagine it would be difficult to implement.

avr-gcc follows the C standards very well. You say: "I don't like it." Sometimes non-standard, non-portable behavior *is* convenient in the short term -- but it has unpleasant consequences in the long term.


reply via email to

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