February 2011 - Wine-devel - list.winehq.org

Re: msvcr90: Fixed a typo
by Nikolay Sivov 04 Feb '11

04 Feb '11

On 2/4/2011 18:33, André Hentschel wrote: > --- > dlls/msvcr90/msvcr90.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/msvcr90/msvcr90.c b/dlls/msvcr90/msvcr90.c > index 2c811cb..d2a61dd 100644 > --- a/dlls/msvcr90/msvcr90.c > +++ b/dlls/msvcr90/msvcr90.c > @@ -315,7 +315,7 @@ const char * __thiscall MSVCRT_type_info_name_internal_method(type_info * _this, > if (!_this->name) > { > /* Create and set the demangled name */ > - /* Nota: mangled name in type_info struct always start with a '.', while > + /* Note: mangled name in type_info struct always start with a '.', while > * it isn't valid for mangled name. > * Is this '.' really part of the mangled name, or has it some other meaning ? > */ Maybe 'starts with' ?

2 1

Re: user32: Add a test for reparenting a WS_POPUP window to a WS_CHILD parent.
by Alexandre Julliard 04 Feb '11

04 Feb '11

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > + SetLastError(0xdeadbeef); > +todo_wine > + ok(SetForegroundWindow(popup), "SetForegroundWindow() error %d\n", GetLastError()); It would be interesting to test what the foreground window is actually set to. > + SetLastError(0xdeadbeef); > + ok(DestroyWindow(parent), "DestroyWindow() error %d\n", GetLastError()); Please don't add invalid uses of GetLastError again, this was cleaned up recently. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: Add a test for reparenting a WS_POPUP window to a WS_CHILD parent.
by Joris Huizer 04 Feb '11

04 Feb '11

Hello Dmitry Timoshkov, I noticed a small issue in your patch: > > - ret = DestroyWindow(parent); > - ok( ret, "DestroyWindow() error %d\n", > GetLastError()); > + ok(DestroyWindow(parent), "DestroyWindow() > error %d\n", GetLastError()); Please don't merge the call with the ok() statement; the GetLastError() call might be executed before the function to be tested, thus giving the old value. (There has been some cleaning up for this issue recently) The same goes for a few tests you added: > + SetLastError(0xdeadbeef); > + ok(SetForegroundWindow(popup), > "SetForegroundWindow() error %d\n", GetLastError()); > + SetLastError(0xdeadbeef); > +todo_wine > + ok(SetForegroundWindow(popup), > "SetForegroundWindow() error %d\n", GetLastError()); > + > + SetLastError(0xdeadbeef); > + ok(DestroyWindow(parent), "DestroyWindow() > error %d\n", GetLastError()); > + HTH, Joris

2 1

RE: Correction to crash inside RtlCaptureStackBackTrace() + test case
by Janne Hakonen 04 Feb '11

04 Feb '11

> > It doesn't need a try-except block, just better wrap-around handling. > Ah, you mean to enhance the if-check? Well..., to me it seems that there is a problem with the 2nd check: "(void *)(frame + 1) >= NtCurrentTeb()->Tib.StackBase" If frame is 0xffffffff or close to it (e.g. 0xfffffffc), adding 1 to its address makes it overflow and the left side becomes 0x3, or 0x0 in 0xfffffffc's case. And that would make the check fail. I would propose that this would be corrected with an additional overflow check. There are two 4 byte values that needs to be read: next frame address and return address. So, it would be checked that address of last byte of return address (frame + 7 bytes) is not smaller than current frame address, right? The if-check would then be as follows: if (((void *)frame < NtCurrentTeb()->Tib.StackLimit) || ((void *)(frame + 1) >= NtCurrentTeb()->Tib.StackBase) || ((ULONG_PTR)frame & 3) || ((ULONG)((char *)frame + 7) < (ULONG)frame)) ... I'm not quite sure if casting pointers to ULONG for comparison is wise move, but can't think anything else for that. Do you think there is any problems with this approach? Other alternative could be to just simply check if the frame pointer equals to 0xfffffffc, that, combined with "(ULONG_PTR)frame & 3" should handle all cases near 0xffffffff. Best Regards, Janne

2 3

Re: wined3d/arb_program_shader: Small optimization in state_texfactor_arbfp().
by Stefan Dösinger 04 Feb '11

04 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.02.2011 um 23:01 schrieb Adam Martinson: > > Oddly enough this gives us an average 1.8% boost in the 3DMark06 batch size tests. Impressive. One more thing you could investigate(but that doesn't affect this patch): Try to figure out why this code is called in the first place. The only situation when this should happen is if the app is using fixed function fragment processing. I wouldn't expect that 3Dmark06 does that. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNS8aYAAoJEN0/YqbEcdMwI1AQAJder+8LZILzdT+8tA2YiwZ+ ZEVOi4S2voFASHUVJbYuWIXkzzVu6fQlZXw/KCyvdQaslpTWQFFc/cOMXcCVjVs5 puJJDydjCyI8FZF7ec8dCIjCHqBH4S91kxDjRmWGifdp1Qd6h/f7o1xyhOHG62xG XZbY1xx3DhQ7lRxRtsdqqq22MM5cOqR4mCen2YPGsd04rlwsxW6zuxZ32oBof0rO ggzBW1F2WdDHeT6rcDK5Iv7R4zdSCtl6IXfsMaT1frTcd8Mo/9jLj7GaLMnQ/UtG JkyQbCP59AOtEKU8nwrISn71YMRkCBHOttaIAVhr6Nq02eNmcxWomSbIsb293LzP fQHFDPJ2aO161AimO/7Nk6DbGniUtlgRGhPhrK+YJvrAhftrtZ2gFUaN3QLJgcKA HHhkU00NsBXOJvz8YuGFDRVmpPpCLcGM7gvMIyjYy3x3W1FWO4giNxnj6CxqHmLs ohkAbsLEnJohhpTyVEaQKTG0Zq49s5WcvkjQbmncqKdP2D9NHmi50FI8MbJJxXAu mMW6sA6oExn31Fnm1/pQOWCZk8hidK1hRN7f25nSRa58q7bSvNT/Gw3kk6S8T5CU yL3r5UIb64ss4QmtXY8SPIR9IDNvmnYUX4/Av/iKpZrSRHCHzpYX7Eecp2jdV/ta jgKpR4VaDyemyij093oW =LXas -----END PGP SIGNATURE-----

1 1

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (resend)
by Paul Vriens 04 Feb '11

04 Feb '11

On 02/04/2011 09:32 AM, Austin English wrote: > - ret = funcs->pfnObjectTrust(&data); > + funcs->pfnObjectTrust(&data); > + ok(ret == S_FALSE, "Expected S_FALSE, got %08x\n", ret); This doesn't look correct (you are removing the assignment and then check it). I know that this code path will never be taken, but still. -- Cheers, Paul.

2 1

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (1/4)
by Juan Lang 04 Feb '11

04 Feb '11

Hey Austin, + ok(ret == S_FALSE, "Expected S_OK, got %08x\n", ret); Copy/pasto. --Juan

2 1

Re: wintrust/tests: make sure return values are used (LLVM/Clang) (3/4)
by Juan Lang 04 Feb '11

04 Feb '11

Hey Austin, ok(ret, "WintrustSetRegPolicyFlags failed: %d\n", GetLastError()); size = sizeof(flags1); r = RegQueryValueExA(key, State, NULL, NULL, (LPBYTE)&flags1, &size); - ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); + ok(!r || r == ERROR_FILE_NOT_FOUND, "RegQueryValueEx failed: %d\n", r); + if (!r) + ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); It seems to me that the introduction of ERROR_FILE_NOT_FOUND weakens the test. (Testing r should be done, thanks for fixing that.) I assume that, since WintrustSetRegPolicyFlags should have succeeded, the registry value should now exist. Is there a test failure you're also trying to fix? Thanks, --Juan

2 1

updated LLVM/Clang static analysis results (and valgirind :-))
by Austin English 04 Feb '11

04 Feb '11

Original results: Date: Thu Jan 20 22:59:57 2011 All Bugs 2922 Argument with 'nonnull' attribute passed null 99 Idempotent operation 154 Dead assignment 1464 Dead increment 155 Dead initialization 22 Array subscript is undefined 5 Assigned value is garbage or undefined 96 Branch condition evaluates to a garbage value 10 Called function pointer is null (null dereference) 6 Dereference of null pointer 757 Dereference of undefined pointer value 8 Division by zero 12 Function call argument is an uninitialized value 49 Garbage return value 9 Result of operation is garbage or undefined 74 Undefined allocation of 0 bytes 2 New results: All Bugs 2817 Argument with 'nonnull' attribute passed null 100 Idempotent operation 156 Dead assignment 1368 Dead increment 152 Dead initialization 22 Array subscript is undefined 4 Assigned value is garbage or undefined 96 Branch condition evaluates to a garbage value 9 Called function pointer is null (null dereference) 6 Dereference of null pointer 757 Dereference of undefined pointer value 8 Division by zero 12 Function call argument is an uninitialized value 46 Garbage return value 7 Result of operation is garbage or undefined 72 Undefined allocation of 0 bytes 2 Available at: http://austinenglish.com/logs/clang_analyzer/index.html and valgrind logs: http://austinenglish.com/logs/valgrind/ if you've looked at valgrind logs and see errors that should be suppressed, please email me and I'll add them. Cheers, Austin

1 0

Re: Re: user32/tests: Test for behavior of WM_SETTEXT handler (try 2)
by Marvin 04 Feb '11

04 Feb '11

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 http://testbot.winehq.org/JobDetails.pl?Key=8839 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0