[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