Improve handling of invalid input in dlls/comctl32/datetime.c

[Nikolay Sivov]

On 12/26/2009 00:47, James McKenzie wrote:
> Nikolay Sivov wrote:
>    
>> Why? There's no default case, treat is as 'if () {} else if () {} etc.'.
>> It's the same thing to have explicit initializers for all local
>> variables even if I don't use it before
>> set some value. It's a pollution, especially if used to silence
>> analyzer warnings.
>>      
> Nikolay:
>
> Things can and do go 'wrong'.  For instance, you build on Linux, I build
> on a Mac.  Sometimes the ported programs from UNIX can and will do
> 'strange' things.  If you don't have a method to know that there is an
> error, then you go about blaming Wine when it is a poor program port.
>    
That's a Mac build environment then. If there's no real problem now, 
there's no point to add such
workarounds, if it is then a compiler should be fixed.
> Also, it is good programming practice to account for the situations you
> don't expect to encounter and to initialize variables that you will be
> using.  This is not a 'just in case' thing, it can help when program
> errors occur to see where in the code an expected value did or did not
> happen.
>    
It also hides things sometimes and adds noops.
> I know, it looks like pollution, but when code goes wrong, and it will,
> this makes troubleshooting much easier.
It will go wrong only due a build problem or something like that, it 
such case you can't trust a line.
>    I know this from running
> Quality Assurance testing for many years and coding myself.  My
> programming instructor deducted grade points for failing to handle error
> and other unexpected conditions.
>
>    
Ok, in theory yes, but I'm speaking about a particular piece.
> James McKenzie
>    
Anyway, my point is that code in subject is clear and can't cause 
problems patch tries to predict -
it's the same condition used twice.

I really have nothing to add here, let's see Alexandre's opinion.