wined3d: Better validation of BltFast destination
iarnell at gmail.com
Wed Jun 23 04:42:02 CDT 2010
On Wed, Jun 23, 2010 at 10:47 AM, Stefan Dösinger
<stefandoesinger at gmx.at> wrote:
> Am Mittwoch 23 Juni 2010 10:40:30 schrieb Stefan Dösinger:
>> You're catching only the GDI surface case here since opengl surfaces don't
>> use IWineD3DBaseSurfaceImpl_BltFast. I recommend to put this check into
>> ddraw, like in your previous attempts(but keep checking for < 0, don't do
>> any bit testing magic like in your old patches)
I'd hope that the opengl implementation also has some checking of its own.
I did the nasty bit twiddling to avoid making any assumptions about
equivalence of types (is it always safe to assume that DWORD can be
cast as a LONG?). And gcc optimizes dstx < 0 away as "comparison of
unsigned expression < 0 is always false".
>> Am Dienstag 22 Juni 2010 23:37:20 schrieb Iain Arnell:
>> > Scratch this - after thinking again about Henri's hint, I've moved the
>> > fix to wined3d.
> I searched the archives to see if I missed any of Henri's suggestions but I
> couldn't find any like that. My consideration is that ddraw already has the
> other range checks, so it would just be consistent to keep it there. besides,
> in many situations ddraw, d3d8 and d3d9 have different checks or behavior in
> case of wrong parameters(see for example surface locking)
> (ok, the latter is somewhat academic since only ddraw calls BltFast directly)
Henri's magic words were simply "integer overflow". So I looked for
the point where this actually happens. And I could make the same
argument for making the check in wined3d - it also makes a whole bunch
of range checks.
But, of course, I'm willing to bow to your better judgement.
More information about the wine-devel