[PATCH 1/2] gdi32/tests: Don't treat a return value of COMPLEXREGION from IntersectClipRect() as broken.

Zebediah Figura z.figura12 at gmail.com
Wed Jan 1 11:34:37 CST 2020

On 12/31/19 10:53 PM, Dmitry Timoshkov wrote:
> Zebediah Figura <z.figura12 at gmail.com> wrote:
>>> Even if every Windows version returns broken result doesn't make it
>>> legitimate to return COMPLEXREGION when the region contains only 1
>>> rectangle. This is clearly broken.
>> Windows does many things that are nonsensical, buggy, or contradicting 
>> their own documentation or other parts of the code. This seems nothing 
>> new. If sufficiently motivated one could even argue that a simple region 
>> is a special case of a complex region (I wouldn't actually be that 
>> surprised if such reasoning led a Windows programmer to just always 
>> return COMPLEXREGION because it was easier for them).
> That's a pretty flawed argumentation, according to the tests the APIs
> that return region type are not limited to COMPLEXREGION, they also
> return SIMPLEREGION when appropriate. In any case adding more convincing
> tests is always welcome if you really think that IntersectClipRect()
> should always return COMPLEXREGION regardless of rectangle count in
> the resulting region and type of the DC.
>> Are we abandoning 
>> the idea of bug-for-bug compatibility now?
> Bug for bug compatibility makes sence only if there's an application that
> depends on particular behaviour, as far as I know that's not the case here.
>> I'm not arguing that we have to return COMPLEXREGION to satisfy the test 
>> (I certainly have no intention of writing such a patch), but our tests 
>> document the behaviour of Windows functions, not their documentation; 
>> that's why they exist.
> Current tests perfectly follow this documentating purpose rule, if they
> don't adding more comments or tests is the right thing to do instead.

I still disagree, but I have no intention of furthering this argument,
it's clearly counterproductive and gets nowhere. I'll leave it up to Huw
and/or Alexandre to decide.

More information about the wine-devel mailing list