>Joao Carlos Mendes Luis wrote:
>>   Personally, I call it programming discipline: "NEVER leave a variable,
>> any variable, without initialization !"

>Fortunately, ANSI C guarantees that all objects, that have static
>storage class, will always be initialised. In the absence of an
>explicit initialiser, the default initialisers are either 0 (for
>integer types), 0.0 (floating point types) or null (pointers).
>The default initialiser for an array or structure is the recursive
>default for each component; the default initialiser for a union is
>the default for its first component.

True enough.  No problems with that.

>As for objects of automatic storage class, I doubt whether it makes
>sense to always include an explicit initialiser in the declaration.
>It may be "programming discipline" to do so, but quite often there
>won't be any usefull initialiser value. In those cases the explicit
>initialiser will be, at best, misleading to the programmers that
>have to maintain the code. Worse than that, those fake initialisers
>might mislead the compiler and bug-tracking tools.

I do have problems with people giving sweeping generalities that this
is a bad thing.  You may not like to do it, for reasons you consider
valid.  However, it is not considered bad style by everyone.  And, "at
best" there is a lot more benefit than you acknowledge.

Many programmers only think about how it affects them while they're
writing the code.  You must also think about people who will be
maintaining, and possibly adding bug fixes, or even new features, to
your code.  Someone trying to do a quick bug fix might accidentally
insert new code before your initializer, and not thoroughly test it.
And, I'm not sure how it adversely affects bug-tracking tools.

There are often good initializing values.  Pointers could always get
NULL.  Ints zero.  Booleans false.  Etc.  Isn't this what you're
saying static values always get?  How come these are bad defaults for
automatic variables, but not for static?

In addition, pre-initializing all pointers to NULL, then re-setting
them to NULL anywhere in the function where they become invalid
(free(pVar); pVar = NULL;) makes bugs easier to find, and makes for an
easy check at the exit point of the function (Exit: if (pVar)
free(pVar);).

This also ties to two more useful style points: single point of entry,
and single point of exit for all functions (no return()s in the
middle); and free all resources at the point of exit, not in the
middle.  These make it much easier to see and catch errors where a
missed return failed to free a resource, or execute some cleanup code.

Admittedly, these are all good user-space practices, IMHO.  The kernel
can sometimes be a place where special cases are encouraged, for
various reasons.

Bottom line: if you don't like it, hey, don't do it; but don't tell
everyone that it's a style that borders on dangerous.

-----------------------------------------------------------------------------
  Michael L. VanLoon                                 michaelv@HeadCandy.com
        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
               Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX...
    NetBSD ports in progress: PICA, others...
-----------------------------------------------------------------------------