[tz] proposed changes for Win32 and a improved mktime() algorithm

[Paul.Koning at dell.com]

> On May 10, 2017, at 10:51 AM, Paul Eggert <eggert at CS.UCLA.EDU> wrote:
> 
> On 05/10/2017 04:34 AM, Kees Dekker wrote:
>> I forgot something: warnings about not initialized variables are almost always triggered because there is a
>> If else[/if else].. codepath, where one of the codepaths uses a variable that is not initialized somewhere.
> Yes, here's an example of the problem:
> 
>   bool ok = complicated condition;
>   int value;
>   if (ok)
>     value = complicated expression;
>   complicated actions;
>   if (ok)
>     return value;
> 
> An inferior compiler might complain that 'value' might be used uninitialized. One can pacify such a compiler by changing line 2 to 'int value = 0;', and you're correct that this typically won't slow the code down significantly. However, such a change obfuscates the source code, as the reader is left wondering why the unnecessary initialization is present. Instead, it's better to disable or ignore the bogus warnings, or get a better compiler. After all, there's nothing wrong with this code, and your compiler is supposed to be your servant not your master.

In GCC at least, you can suppress the warning with an extension: "int foo = foo;" which means "don't initialize but don't bug me".  That has the nice property of expressing exactly what you intended, as opposed to initializing with an actual value.

BTW, because of the halting problem, it's not valid to say that a warning is a sign of an inferior compiler.  For some values of "complicated condition" it might be, although even then it would be a matter of opinion (to wit, is it reasonable for a compiler to limit compile time evaluation).

	paul