nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] too many uninitialized variables in nmh-1.1 RC4


From: Igor Sobrado
Subject: Re: [Nmh-workers] too many uninitialized variables in nmh-1.1 RC4
Date: Fri, 25 Nov 2005 19:00:48 +0100

In message <address@hidden>, Oliver Kiddle writes:
> 
> I would be inclined to think that clearing up compiler warnings is
> something we should leave until after the release.

I suppose that I answered this post some days ago, but obviously
I was wrong.  I am sorry for the delay.

I fully agree with you.  Fixing these aesthetical or minor bugs
when the deadline for the next stable version will arrive very soon
is something that must be avoided.  On the other hand, I agree
that some of these bugs are probably mistakes in the source code
analysis.  I should check it using other compilers (e.g., the SGI
C compiler on IRIX, or the HP C compiler in HP-UX) before "fixing" it.

> I've looked at a number of the instances flagged by the compiler and it
> is generally always the case that the compiler is wrong: the full
> program logic doesn't allow the variable to be used without
> initialisation. The question is how to deal with these because it'd be
> nice if we could prevent the compiler warnings. In some ways I think it
> is wrong to needlessly assign 0 to such variables because it implies to
> someone reading the code that the variable needs to be initialised to 0
> and that that value has a purpose.

Agreed.  The most important issue here is assuring that a variable
cannot be used without initializing it.  A default value unneedlessly
assigned to it can certainly make people reading code to assume that
this variable *needs* to be assigned to that value in that part of
the code.  Sometimes it is clear and better not assigning a value
to a variable, and it is perfect if the program logic assures that
the variable will not be used without being initialized.

You are absolutely right on these matters.

Best regards,

Igor.




reply via email to

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