Re: [ng-spice] Compilation Warnings


To ng-spice@ieee.ing.uniroma1.it
From Arno <A.W.Peters@ieee.org>
Date Fri, 3 Sep 1999 00:53:04 +0200
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
In-Reply-To <Pine.LNX.3.96.990901215622.15692A-200000@voyager >
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
References <Pine.LNX.3.96.990901215622.15692A-200000@voyager >
Reply-To ng-spice@ieee.ing.uniroma1.it
User-Agent Mutt/1.0pre1i

On Wed, Sep 01, 1999 at 09:58:29PM +0200, Paolo Nenzi wrote:
> This is the output of a typical ngspice compilation. Can you tell me why
> there are so may unitialized symbol ? Should we silently assign them a
> zero value to avoid the waring ?

[lots of warning messages snipped]

The message means there can be a code path that uses that variable
without it being properly initialized.  Each and every of these
warnings is a potential bug.

It seems to me a little shortsighted to handle this by preemptivly
assigning the variables to zero.  If it had been so easy, I would have
used that approach while I was removing the `unused variable' warning
messages.  Unfortunately, it isn't.  However, in some cases it is a
easy as assigning the default value.  Take for example the following
warning:

> cktpzstr.c:514: warning: `error' might be used uninitialized in this 
>function

the code basically goes like this:

    int func(int args)
    {
        int error;

        case(args) {
        case 1:
             error = SOME_ERROR;
             break;
        case 2:
             error = SOME_OTHER_ERROR;
             break;
        }

        return error;
    }

Note that in this case the value of `error' is undefined in case args
does not equal 1 or 2.  A possible way to deal with this warning, is
by adding the following line to the top of the function:

  error = OK;

These things _are_ relatively easy to fix.  I encourage you to go and
find those in the source.  Please leave those warning messages in
where a resolution is not as easy.  They keep us aware there are still
issues to be resolved.  Assigning variables to zero to keep the
compiler happy is like shuffling the problems under the rug.

Regards,
-- 
Arno

Partial thread listing: