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

[hutchinsonandy]

I agreed

ROM is not reuseable or infinite thus cannot be auto.

The keyword should either:

1)  Be rejected as invalid
2) carry a warning if the static qualifier is missing - and assume 
static (or auto )
or
3) Assume static usage in the function context - and be noted as such.

Where it appears to assume "auto" with no warning, which seems 
undesirable and much more surprising that the above.


I vote it is bug.







-----Original Message-----
From: Dave N6NZ <address@hidden>
To: AVR-GCC <address@hidden>
Sent: Tue, 13 May 2008 12:45 pm
Subject: Re: [avr-gcc-list] prog_mem limitation?


 
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? 
> >  
> > Eric 
> > > 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. 
 
-dave 
 
 
_______________________________________________ 
AVR-GCC-list mailing list 
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list