Kean Johnston wrote:
>> A common situation would be:
>>
>> if (condition) {
>> flag = 1
>> msg = "Hello World";
>> } else
>> flag = 0; [1]
>> ...
>> if (flag)
>> printf ("I say, %s\n", msg); [2]
>>
>> Point [1] is where I "fail" to init 'msg', point [2] is where I
>> use it. I know that the program is safe, and if the flow analysis
>> can relate 'flag' and 'msg' then the warning would go away.
>>
>> Which one would we want listed in the proposed new warning, 1 or 2?
>
> Definately 2. I wont say it is *impossible*, but I think
> it is asking way too much of the compiler to warn about 1.
> It implies a level of understanding of the flow of the
> program that is completely unrealistic. However, warning at
> 2 should be trivial. Where this level of detail in the
> warning is useful is if you have a particularly large function,
> with the variables declared at the top (not at the top of, say,
> and enclosing if() block). Its even worse when the code is
> full of pre-processor conditionals. By telling me that 2
> (or all instances of type 2), it saves me looking at *every*
> usage of msg. It's just plain more useful, IMHO :)
>
> Kean
Yes, [2] tells you where the risk lies, yet in order to fix it [1]
will be very useful. And yes, [1] is harder to do, but that never
stopped any gcc project :-)
In short, let's have [2] now and hope for [1] in the future.
--
Eyal Lebedinsky ([EMAIL PROTECTED]) <http://samba.org/eyal/>
attach .zip as .dat
