[Top][All Lists]

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

Re: [avr-gcc-list] GCC Functions

From: Joerg Wunsch
Subject: Re: [avr-gcc-list] GCC Functions
Date: Tue, 27 Nov 2001 13:38:55 +0100 (MET)

Paulo Abreu <address@hidden> wrote:

>>This is basically a do-nothing, since ledlight is already 0x0 (per
>>definition, since it's a global variable).
> An opinion: initializing a variable to 0 is not a C standard.

You are wrong: it is.  Please go and read the standard before telling
wrong things ;-), reading the second edition of K&R would already do.

> So, it is not a good approach assuming that all compilers will act
> as you state. Code will be more portable if you follow standards.

It will only be portable to very non-standard compilers.  But even
pre-ANSI compilers that adhere to the old K&R standard (could mostly
be found on very old Unixen) already followed the convention to zero
out global storage.  Any compiler that declares __STDC__ (to the value
1) /must/ care to initialize global variables, otherwise it's broken.

As already explained here, this "be safe and initialize it manually to
0" habit has a very negative impact, in particular in MCU environments
where often each byte counts.  They cause the variable to leave the
..bss section (uninitialized data that will be zeroed at program
startup), and move it into the .data section (initialized data), and
thus make it consume space in your flash ROM, whereas .bss doesn't.
(In environments like Unix, the negative impact is smaller but still
measurable: .bss doesn't cost file space, while .data does.  Also,
program startup becomes less efficient, since zeroing entire pages for
..bss can often be handled more effectively than having to load the
..data pages from the file...  But that's getting off-topic here.)

So unless you really want to initialize the variable to something else
than 0, don't do it.

J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/

reply via email to

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