September 2016 - Wine-devel

Re: [PATCH] d3dxof: avoid some strcpy overflows (Coverity)
by Henri Verbeet 06 Sep '16

06 Sep '16

On 4 September 2016 at 11:24, Marcus Meissner <marcus(a)jet.franken.de> wrote: > @@ -532,8 +532,11 @@ static BOOL is_name(parse_buffer* buf) > buf->rem_bytes -= pos; > > TRACE("Found name %s\n", tmp); > + if (strlen(tmp)+1 > sizeof(buf->value)) { > + FIXME("name %s exceeds buffer length\n", tmp); > + return FALSE; > + } > strcpy((char*)buf->value, tmp); > - > return TRUE; > } There are plenty of things wrong with d3dxof, but assuming the preceding code isn't too broken, I don't think this can happen. You should probably just get rid of the "tmp" buffer and use read_bytes() or something similar after calculating "pos" though. (The TRACE can use debugstr_an().) That probably applies to is_string() as well. > @@ -928,6 +937,10 @@ static BOOL parse_template_option_info(parse_buffer * buf) > { > if (get_TOKEN(buf) != TOKEN_NAME) > return FALSE; > + if (strlen((char*)buf->value)+1 > sizeof(cur_template->children[cur_template->nb_children])) { > + FIXME("name %s too long for buffer\n", (char*)buf->value); > + return FALSE; > + } > strcpy(cur_template->children[cur_template->nb_children], (char*)buf->value); Once you've calculated to number of bytes you need to copy anyway, you might as well just use memcpy(). I.e., strcpy() is almost always the wrong choice, for one reason or another.

2 2

Re: [PATCH] winejoystick.drv: Revert 62876f3fc5feb1ca23d27a6de5adca580d963d0c
by Sebastian Lackner 05 Sep '16

05 Sep '16

On 03.09.2016 22:21, Bruno Jesus wrote: > Copy & paste fail on the commit ID in previous email, sorry. > > With Aric's intensive steps into commiting HID code it is simpler to revert this patch (which caused a regression) instead of trying alterantive ways to fix it. Specially because HID will change this whole file anyway. > > Superseeds 126184. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41217 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_linux.c | 35 ++++++++-------------------------- > 1 file changed, 8 insertions(+), 27 deletions(-) I am not sure if it makes much sense to revert your improvements, just because of the ongoing HID work. When I understand the problem correctly, the performance issues can also be fixed without in a different way. I think your previous patch was already in the right direction, my only criticm was the use of malloc/free instead of WINAPI. Regards, Sebastian

3 3

HLSL compiler
by Fabian Maurer 05 Sep '16

05 Sep '16

I'd like to take a try at Directx10 support, firstmost hacking the HLSL compiler (namely implementing "fx_4_0"). No guarantee I'll succeed though. First, is there already someone working on this? Don't wanna duplicate the effort again. Second, since there already is an existing parser: Did you plan to simply extend it and make one parser for all HLSL versions, or to duplicate the code and have it separate for each version like the official compiler did it? I think I'd just add it to d3dcompiler_43.

3 7

Re: dsound: Avoid using the COM method implementations directly.
by Andrew Eikum 05 Sep '16

05 Sep '16

I guess I'm not opposed to this, but are these changes useful? Andrew On Fri, Sep 02, 2016 at 10:37:33AM +0200, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/dsound/capture.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 30870ae..38e3045 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -861,7 +861,7 @@ static ULONG DirectSoundCaptureDevice_Release( > LeaveCriticalSection(&DSOUND_capturers_lock); > > if (device->capture_buffer) > - IDirectSoundCaptureBufferImpl_Release(&device->capture_buffer->IDirectSoundCaptureBuffer8_iface); > + IDirectSoundCaptureBuffer8_Release(&device->capture_buffer->IDirectSoundCaptureBuffer8_iface); > > if(device->mmdevice) > IMMDevice_Release(device->mmdevice); > -- > 2.7.4 > >

3 6

Re: [PATCH 1/2] user32/tests: ValidateRect(NULL, &rect) on >= Win 8 no longer invalidates all windows.
by Marvin 05 Sep '16

05 Sep '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25559 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:11043: Test failed: expected PeekMessage to return FALSE, got 1 === w864 (32 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (32 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:7438: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (64 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (64 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:7438: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000

1 0

Re: [PATCH] msi: avoid potential overflow
by Hans Leidekker 05 Sep '16

05 Sep '16

On Sat, 2016-09-03 at 22:55 +0200, Marcus Meissner wrote: > the create_test_guid function uses MAX_PATH characters > on both passed strings. While it never fully fills them, just > pass in buffers of that size. I'd prefer to fix create_test_guid instead and update callers that pass MAX_PATH buffers accordingly.

1 0

Re: [PATCH 6/6] ddraw/tests: Add D3DVIEWPORT2 transform tests.
by Marvin 03 Sep '16

03 Sep '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25550 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 4/6] ddraw: Apply legacy clipspace to d3d2.
by Marvin 03 Sep '16

03 Sep '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25549 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 3/6] ddraw/tests: Test d3d2 and 3 drawing with non-standard viewports.
by Marvin 03 Sep '16

03 Sep '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25548 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 2/6] ddraw: Store d3d1 projection matrices in device->legacy_projection.
by Marvin 03 Sep '16

03 Sep '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25547 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0