September 2009 - Wine-Devel

Re: [1/3] riched20: Implement handling of WM_KEYDOWN VK_RETURN in a dialog mode.

by Dylan Smith

> 3. Is there any need for storing the hwndParent in editor. Couldn't > the value be obtained by using GetWindowLongW using GWL_HWNDPARENT > after making sure that editor->hWnd is non-NULL (i.e. windowed mode). > Scratch that point, I see that it is tested for using SetParent in the tests after creating the richedit control. Other things I noticed: > + r = SendMessage(hwRichEdit, WM_GETDLGCODE, (WPARAM)NULL, (LPARAM)NULL); Avoid superfluous casts. In this case it is preferred to use 0 instead of casting NULL. If the cast isn't needed, then leave it out (See: http://wiki.winehq.org/SuperfluousCasts) > +struct dialog_mode_messages > +{ > + int wm_getdefid, wm_close, wm_nextdlgctl; > +}; > + > +static struct dialog_mode_messages dm_messages; > + > +static void zero_dm_messages(void) > +{ > + dm_messages.wm_close = 0; > + dm_messages.wm_getdefid = 0; > + dm_messages.wm_nextdlgctl =0; > +} Couldn't memset(dm_messages, 0, sizeof(dm_messages)) be used instead of the special zero_dm_messages function.

Sept. 1, 2009

Re: cpp check run monday Aug 31

by Vincent Povirk

> [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:336]: (error) > Division by zero > [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:337]: (error) > Division by zero http://source.winehq.org/git/wine.git/?a=blob;f=dlls/windowscodecs/bmpencod… I'm going to need someone to explain to me how a division by a literal 0.0254 can be a "Division by zero". -- Vincent Povirk

Sept. 1, 2009

Re: [1/3] riched20: Implement handling of WM_KEYDOWN VK_RETURN in a dialog mode.

by Dylan Smith

On Tue, Sep 1, 2009 at 4:18 AM, Sergey Khodych <khodych(a)gmail.com> wrote: > @@ -2145,6 +2145,31 @@ ME_KeyDown(ME_TextEditor *editor, WORD nKey) > ME_SendRequestResize(editor, FALSE); > return TRUE; > case VK_RETURN: > + if (editor->bDialogMode) > + { > + DWORD dwStyle; > + > + if (ctrl_is_down) > + return TRUE; > + > + dwStyle = GetWindowLongW(editor->hWnd, GWL_STYLE); > + if (!(dwStyle & ES_WANTRETURN)) > + { > + DWORD dw; > + dw = SendMessageW(editor->hwndParent, DM_GETDEFID, 0, 0); > + if (HIWORD(dw) == DC_HASDEFID) > + { > + HWND hwDefCtrl = GetDlgItem(editor->hwndParent, LOWORD(dw)); > + if (hwDefCtrl) > + { > + SendMessageW(editor->hwndParent, WM_NEXTDLGCTL, (WPARAM)hwDefCtrl, (LPARAM)TRUE); > + PostMessageW(hwDefCtrl, WM_KEYDOWN, VK_RETURN, 0); > + } > + } > + return TRUE; > + } > + } > + > if (editor->styleFlags & ES_MULTILINE) > { > ME_Cursor cursor = editor->pCursors[0]; 1. editor->hWnd may be NULL for windowless richedit controls, but you code doesn't seem to take that into consideration. 2. The style flags that you get from GetWindowLongW should probably come from the cached values in editor->styleFlags. 3. Is there any need for storing the hwndParent in editor. Couldn't the value be obtained by using GetWindowLongW using GWL_HWNDPARENT after making sure that editor->hWnd is non-NULL (i.e. windowed mode).

Sept. 1, 2009

Re: cpp check run monday Aug 31

by Henri Verbeet

2009/9/1 chris ahrendt <celticht32(a)yahoo.com>: > [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:320]: (error) Division > by zero > [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:336]: (error) Division > by zero > [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:340]: (error) Division > by zero ... > [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:218]: (error) > Division by zero > [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:219]: (error) > Division by zero > [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:240]: (error) > Division by zero > [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:241]: (error) > Division by zero Although that's not a particularly nice way to generate floating point specials, they're only errors if the relevant exceptions are unmasked. I think it should be safe to assume they aren't in the ddraw tests, and in case of wined3d it won't generate them unless the input data already contained them.

Sept. 1, 2009

cpp check run monday Aug 31

by chris ahrendt

I ran CPP check against the monday git tree using the latest CPP check off their git tree. here is the result : [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:320]: (error) Division by zero [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:336]: (error) Division by zero [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:340]: (error) Division by zero [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/sane.ds/ui.c:842]: (error) Division by zero [/home/cahrendt/wine-git/dlls/sane.ds/ui.c:843]: (error) Division by zero [/home/cahrendt/wine-git/dlls/sane.ds/ui.c:863]: (error) Division by zero [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:336]: (error) Division by zero [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:337]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:218]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:219]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:240]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:241]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:150]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:211]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [/home/cahrendt/wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer dereference: hWndCreated [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (possible error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map chris

Sept. 1, 2009

Re: urlmon: Add test for IsValidURL

by Jacek Caban

Hi Vladimir, Vladimir Pankratov wrote: > Hello all. > > Added test for IsValidURL. > > changed files: > dlls/urlmon/tests/misc.c + { + hr = IsValidURL(NULL, bad_urls[i], 0); + ok(hr != S_OK, "URL %s must be invalid\n", wine_dbgstr_w(bad_urls[i])); It would be better to test the exact error code here. Jacek

Sept. 1, 2009

Re: [PATCH 2/7] dpwsockx: Implementation of SPInit

by Henri Verbeet

2009/9/1 Ismael Barros² <razielmine(a)gmail.com>: > On Tue, Sep 1, 2009 at 11:00 AM, Henri Verbeet<hverbeet(a)gmail.com> wrote: >> 2009/9/1 Ismael Barros <razielmine(a)gmail.com>: >>> +typedef struct tagDPSP_MSG_HEADER >>> +{ >>> + DWORD size; /* size & 0x000FFFFF, token & 0xFFF00000 */ >>> + SOCKADDR_IN SockAddr; >>> +} DPSP_MSG_HEADER, *LPDPSP_MSG_HEADER; >>> +typedef const DPSP_MSG_HEADER* LPCDPSP_MSG_HEADER; >>> + >> It seems you're sending this over the network, so you should make sure >> it's correctly packed, and take the byte order into account. > > I tested it with a wireshark dissector and against the original > implementation, and it seems to work nicely. > Probably, but that depends on how the compiler packs the structure, and on the host byte order.

Sept. 1, 2009

Re: [PATCH 2/7] dpwsockx: Implementation of SPInit

by Ismael Barros²

On Tue, Sep 1, 2009 at 11:00 AM, Henri Verbeet<hverbeet(a)gmail.com> wrote: > 2009/9/1 Ismael Barros <razielmine(a)gmail.com>: >> +typedef struct tagDPSP_MSG_HEADER >> +{ >> + DWORD size; /* size & 0x000FFFFF, token & 0xFFF00000 */ >> + SOCKADDR_IN SockAddr; >> +} DPSP_MSG_HEADER, *LPDPSP_MSG_HEADER; >> +typedef const DPSP_MSG_HEADER* LPCDPSP_MSG_HEADER; >> + > It seems you're sending this over the network, so you should make sure > it's correctly packed, and take the byte order into account. I tested it with a wireshark dissector and against the original implementation, and it seems to work nicely.

Sept. 1, 2009

Re: [PATCH 1/7] dpwsockx: Stub implementation

by Ismael Barros²

dpwsockx is not used by any application, only by us in dplayx, so it's pretty safe to assume we won't pass any invalid parameter, as all the parameters passed by applications are already checked for validity in dplayx. On Tue, Sep 1, 2009 at 11:00 AM, Henri Verbeet<hverbeet(a)gmail.com> wrote: > 2009/9/1 Ismael Barros <razielmine(a)gmail.com>: >> --- >> dlls/dpwsockx/Makefile.in | 2 +- >> dlls/dpwsockx/dpwsockx_main.c | 164 ++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 163 insertions(+), 3 deletions(-) >> > This patch seems to assume the application will never pass NULL for > "data", is that safe to assume? If applications aren't allowed to pass > NULL it's ok to crash, although it might make your life simpler if it > isn't inside a TRACE/FIXME. > > >

Sept. 1, 2009

Re: [PATCH 4/4] openal32: Add thunks for EFX functions

by Chris Robinson

On Tuesday 01 September 2009 1:59:54 am Henri Verbeet wrote: > I suppose 32-bit reads are atomic on x86, provided the variable is > aligned correctly, but shouldn't access to CurrentCtx technically be > synchronized? Probably, but I'm not sure it would be beneficial. If the thread can be interrupted between entering one of the extended functions and the function pointer being called, it would be a pretty nasty race condition. OpenAL doesn't really say what happens when you call a function for a context that's not active (current Windows implementations, if they haven't changed too much, would likely crash, silently fail, or succeed using the wrong device). I'm not sure the cost of an extra lock would be worth it when it could still randomly crash anyway.

Sept. 1, 2009