[Top][All Lists]

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

Re: [avr-gcc-list] Allocation sequence of eeprom variables

From: Juergen Harms
Subject: Re: [avr-gcc-list] Allocation sequence of eeprom variables
Date: Tue, 21 Aug 2012 10:38:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120717 Thunderbird/10.0.6

On 08/20/2012 10:10 PM, David Brown wrote:
Almost certainly, there is something wrong in your code, or in the way
you have declared your external data - the "-Wuninitialized" flag should
not give false positives as you describe.  (It can give false positives,
when you know yourself that all code paths that use the data have
initialised the variables but the compiler is unable to prove this.)

I got rid of most of the "-Wuninitialized" warnings by introducing intermediate typedefs - for instance, replacing

extern  const double    sunrise_fact[] PROGMEM;
typedef double PROGMEM          prog_double;
extern  const prog_double       *sunrise_fact;

One single warning remains that I did not manage to suppress:

extern  const prog_int8_t max_module;

What is wrong with that? max_module is defined in another module and is initialised to a very constant value. The warning message is given when VersionPanel.c is compiled

VersionPanel.c: In function 'ShowCpuInfo':
VersionPanel.c:71:26: warning: uninitialized variable 'max_module' put into program memory area [-Wuninitialized]

and the reference to max_module in ShowCpuInfo is:

    if ( x_value <= pgm_read_byte ( &max_module ) ) {

Any suggestions how to avoid this last warning - would be great if I get back to a make listing without warnings.

reply via email to

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