[2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.

Nikolay Sivov bunglehead at gmail.com
Sat Jul 12 12:37:27 CDT 2008


James Hawkins wrote:
> On Sat, Jul 12, 2008 at 11:56 AM, Nikolay Sivov <bunglehead at gmail.com> wrote:
>   
>> Changelog:
>>    -  Fix GdipPathIterNextMarker behaviour on path without markers. Make tests pass on native.
>>
>> ---
>>  dlls/gdiplus/pathiterator.c       |    3 ++-
>>  dlls/gdiplus/tests/pathiterator.c |    6 +++---
>>  2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/dlls/gdiplus/pathiterator.c b/dlls/gdiplus/pathiterator.c
>> index 55b0782..3d3b1dc 100644
>> --- a/dlls/gdiplus/pathiterator.c
>> +++ b/dlls/gdiplus/pathiterator.c
>> @@ -140,7 +140,8 @@ GpStatus WINGDIPAPI GdipPathIterNextMarker(GpPathIterator* iterator, INT *result
>>     /* first call could start with second point as all subsequent, cause
>>        path couldn't contain only one */
>>     for(i = iterator->marker_pos + 1; i < iterator->pathdata.Count; i++){
>> -        if(iterator->pathdata.Types[i] & PathPointTypePathMarker){
>> +        if((iterator->pathdata.Types[i] & PathPointTypePathMarker) ||
>> +           (i == iterator->pathdata.Count - 1)){
>>             *startIndex = iterator->marker_pos;
>>             if(iterator->marker_pos > 0) (*startIndex)++;
>>             *endIndex   = iterator->marker_pos = i;
>> diff --git a/dlls/gdiplus/tests/pathiterator.c b/dlls/gdiplus/tests/pathiterator.c
>> index 071c1d5..6498bb3 100644
>> --- a/dlls/gdiplus/tests/pathiterator.c
>> +++ b/dlls/gdiplus/tests/pathiterator.c
>> @@ -114,7 +114,7 @@ static void test_nextmarker(void)
>>     GdipCreatePathIter(&iter, path);
>>     stat = GdipPathIterNextMarker(iter, &result, &start, &end);
>>     expect(Ok, stat);
>> -    expect(0, result);
>> +    if(stat == Ok) expect(TRUE, (result == 4) && (start == 0) && (end == 3));
>>     
>
> Why are you checking if stat == Ok?  You're linking what should be
> separate tests together.  You also need to put each of these checks
> into separate tests.  If the test fails, you have no idea (without
> debugging further) which one of those checks fails.  They're called
> unit tests for a reason.
>   
I don't think so. If the call fails testing return value doesn't make 
any sense. In this case 'result' is uninitialized and remains 
uninitialized after a call if it fails (here I mean a native too). So 
why should we check something which has unpredictable value?
By the way first time I saw this here 
8fd6f0e26ae28f2ba4938e2fbcc4851f47baa53c..
 



More information about the wine-devel mailing list