[PATCH 0/1] MR1950: widl: Initialize __frame to a default value (Coverity)

[Alistair Leslie-Hughes (＠alesliehughes)]

In the generate code, Converity is reporting __frame->code unitilized in the failed case.
When we initialize the object, then __f will also point to a fully initizliaed structure.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1950

[PATCH 1/1] widl: Initialize __frame to a default value (Coverity)

[Alistair Leslie-Hughes]

From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>

In the generate code, Converity is reporting __frame->code unitilized in the failed case.
When we initialize the object, then __f will also point to a fully initizliaed structure.
---
 tools/widl/proxy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c
index a80aa5d77fe..a8d46e1869d 100644
--- a/tools/widl/proxy.c
+++ b/tools/widl/proxy.c
@@ -221,7 +221,7 @@ static void gen_proxy(type_t *iface, const var_t *func, int idx,
   print_proxy( ")\n");
   print_proxy( "{\n");
   indent ++;
-  print_proxy( "struct __proxy_frame __f, * const __frame = &__f;\n" );
+  print_proxy( "struct __proxy_frame __f = {0}, * const __frame = &__f;\n" );
   /* local variables */
   if (has_ret) {
     print_proxy( "%s", "" );
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/1950

[PATCH 1/1] widl: Initialize __frame to a default value (Coverity)

[Marvin]

Hi,

It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.

The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:

The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=128366

Your paranoid android.


=== debian11 (32 bit report) ===

user32:
msg.c:19187: Test failed: SendMessage from other thread 1: 1: the msg 0x0400 was expected, but got msg 0x0403 instead
msg.c:19187: Test failed: SendMessage from other thread 1: 2: the msg sequence is not complete: expected 0000 - actual 0400
msg.c:19201: Test failed: wrong status 00080000
msg.c:19207: Test failed: SendMessage from other thread 3: 0: the msg 0x0403 was expected, but got msg 0x0401 instead
msg.c:19207: Test failed: SendMessage from other thread 3: 1: the msg sequence is not complete: expected 0401 - actual 0000

[Zebediah Figura (＠zfigura)]

In what case is __frame->code used uninitialized?

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1950#note_20831

[Alistair Leslie-Hughes (＠alesliehughes)]

When RpcTryExcept fails, eg
> if (!__wine_setjmpex( &__frame->jmp, &__frame->frame ))<br>
> {...}<br> else<br>
> _RetVal = NdrProxyErrorHandler(RpcExceptionCode());<br>

where RpcExceptionCode() (__frame->code)

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1950#note_20832

[Zebediah Figura (＠zfigura)]

In that case we've been through the exception handler, which (always) sets the "code" member. Does Coverity not know how to deal with setjmp/longjmp? We have __returns_twice__ set on __wine_setjmpex()...

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1950#note_20834

[Alistair Leslie-Hughes (＠alesliehughes)]

I really don't know.
If Coverity is seeing the C version of __wine_setjmpex then frame parameter isn't used and might be the cause of the issue.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1950#note_20837