For the record, this is how this has been addressed a few months
after this discussion. That's another way of doing it. :-)
Gerald
commit 1af17844301c4924dd8324cbf2f9c3c1ef0394b2
Author: Huw Davies
Date: Tue May 4 14:05:13 2010 +0100
comctl32: Silence a few compiler warnings.
diff --g
Nikolay Sivov wrote:
> 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 so
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 use
Nikolay Sivov wrote:
> On 12/26/2009 00:04, James McKenzie wrote:
>> Nikolay Sivov wrote:
>>
>>> On 12/25/2009 14:18, Gerald Pfeifer wrote:
>>>
Otherwise max_count will be undefined in the following loop may do
interesting things it seems. (Does Coverity diagnose similar items?)
On 12/26/2009 00:04, James McKenzie wrote:
Nikolay Sivov wrote:
On 12/25/2009 14:18, Gerald Pfeifer wrote:
Otherwise max_count will be undefined in the following loop may do
interesting things it seems. (Does Coverity diagnose similar items?)
Gerald
ChangeLog:
Improve handling of i
Nikolay Sivov wrote:
> On 12/25/2009 14:18, Gerald Pfeifer wrote:
>> Otherwise max_count will be undefined in the following loop may do
>> interesting things it seems. (Does Coverity diagnose similar items?)
>>
>> Gerald
>>
>> ChangeLog:
>> Improve handling of invalid input in DATETIME_ReturnField
On 12/25/2009 14:18, Gerald Pfeifer wrote:
Otherwise max_count will be undefined in the following loop may do
interesting things it seems. (Does Coverity diagnose similar items?)
Gerald
ChangeLog:
Improve handling of invalid input in DATETIME_ReturnFieldWidth.
diff --git a/dlls/comctl32/datet