It achieves exactly the same effect. I would be surprised it if even compiled down to different instructions. So, aside from not being wrapped in an extra set of comfy braces… why are we afraid of goto again? I agree it can be very effective at making spaghetti code, but this is one of the two cases where I think it makes sense. I don’t believe in shunning useful syntax that has no negative side effects, just because of cargo cult wisdom. But I do respect your point of view. Sincerely, what’s the big deal?
By default, avr-gcc will initialize variables to zero (or the equivalent, depending on type), so giving them an explicit initial value of zero does nothing but consume flash storage.
True for global variables only but NOT for local variables. Local variables should ALWAYS be initialized by the programmer before any use other than assignment!
Huh… Are you sure?
Quoting from the avr libc FAQ:
Global and static variables are guaranteed to be initialized to 0 by the C standard. avr-gcc does this by placing the appropriate code into section .init4 (see The .initN Sections). With respect to the standard, this sentence is somewhat simplified (because the standard allows for machines where the actual bit pattern used differs from all bits being 0), but for the AVR target, in general, all integer-type variables are set to 0, all pointers to a NULL pointer, and all floating-point variables to 0.0.
(Interesting, but less relevant, details snipped.)
Now if some programmer “wants to make doubly sure” their variables really get a 0 at program startup, and adds an initializer just containing 0 on the right-hand side, they waste space. While this waste of space applies to virtually any platform C is implemented on, it’s usually not noticeable on larger machines like PCs, while the waste of flash ROM storage can be very painful on a small microcontroller like the AVR.
So in general, variables should only be explicitly initialized if the initial value is non-zero.
Recent versions of GCC are now smart enough to detect this situation, and revert variables that are explicitly initialized to 0 to the .bss section. Still, other compilers might not do that optimization, and as the C standard guarantees the initialization, it is safe to rely on it.
(All emphasis mine.)
This says nothing about (non-static) local variables specifically, but the closing paragraphs above the note, combined with the line in the first paragraph where it states “ALL integers …, ALL floats …, ALL pointers…” could be taken to mean… well… ALL variables.
Nick did include a snippet of disassembled output that shows no evidence of setting a default value, although that could easily be because the variable was never read before having a value assigned to it. That is well within the compiler’s purvue to optimize out its own useless initialization. Having never checked the case myself where a variable IS read (on AVR!!) without initialization first, I can’t say which is the case for local variables. If someone doesn’t beat me to it, I’ll try to remember to check tonight when I get home.
Alternatively, it could mean that memory is initialized to zero through non-code means. Will have to peruse the data sheet on that account…