When initializing a jsstr_inline_t with a len < 3, the size passed
for the allocation is smaller then the size of the structure
(as the later is rounded up to the alignment = 4 bytes).

GCC 12.2 complains about this when dereferencing the pointer to
the structure as the size passed for allocation is smaller than the
size of the structure.

The warning is fixed by using flexible array member in
jsstr_inline_t. Given the rounding behavior in memory allocation, this
should not change the size of allocated blocks.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=36312

This is called early in process startup; malloc() should definitely never fail here.

This fixes an uninitialized variable warning with gcc 12.2:

In function ‘build_initial_params’,
    inlined from ‘init_startup_info’ at ../wine/dlls/ntdll/unix/env.c:2004:18:
../wine/dlls/ntdll/unix/env.c:1910:12: error: ‘env_pos’ may be used uninitialized [-Werror=maybe-uninitialized]
 1910 |     path = get_env_var( env, env_pos, pathW, 4 );
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../wine/dlls/ntdll/unix/env.c: In function ‘init_startup_info’:
../wine/dlls/ntdll/unix/env.c:1903:18: note: ‘env_pos’ declared here
 1903 |     SIZE_T size, env_pos, env_size;
      |                  ^~~~~~~

GCC complains about writing 4x4 floats into a pointer to a float.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Windows when using cached credentials will use them on the first challenge,
if then a second 403 (ACCESS_DENIED) is received, the user is prompted again
but this time with the password and save checkbox cleared.
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com>

The data type for "done" was accidentally changed in e29dc33a.

BOOL is basically the same as UINT32, but it should only be used for flags.
BOOLEAN would be better for that though, as it's single-byte.

The function takes the number of (wide) characters in input, not bytes.

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com>

This works around a spurious gcc warning:

../wine/dlls/win32u/message.c: In function ‘unpack_message.constprop’:
../wine/dlls/win32u/message.c:359:9: error: writing 28 bytes into a region of size 4 [-Werror=stringop-overflow=]
  359 |         memcpy( &ps->wp, &wp, sizeof(wp) );
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../wine/dlls/win32u/win32u_private.h:29,
                 from ../wine/dlls/win32u/message.c:30:
../wine/include/ntuser.h:549:15: note: destination object ‘hwnd’ of size 4
  549 |     UINT      hwnd;
      |               ^~~~

This works around a spurious gcc warning:

../wine/dlls/ntdll/unix/system.c: In function ‘NtQuerySystemInformation’:
../wine/dlls/ntdll/unix/system.c:3176:36: error: ‘%s’ directive output between 0 and 2147483644 bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-truncation=]
 3176 |         snprintf( info, size, "%s%c%s%c%s%c%s", version, 0, wine_build, 0, buf.sysname, 0, buf.release );
      |                                    ^~                       ~~~~~~~~~~
../wine/dlls/ntdll/unix/system.c:3176:9: note: ‘snprintf’ output between 8 and 2147483780 bytes into a destination of size 4294967295
 3176 |         snprintf( info, size, "%s%c%s%c%s%c%s", version, 0, wine_build, 0, buf.sysname, 0, buf.release );
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

gcc warns about this:

../wine/libs/wine/mmap.c: In function ‘wine_mmap_add_reserved_area_obsolete’:
../wine/libs/wine/mmap.c:504:9: error: the comparison will always evaluate as ‘true’ for the pointer operand in ‘(char *)addr + (sizetype)size’ must not be NULL [-Werror=address]
  504 |     if (!((char *)addr + size)) size--;  /* avoid wrap-around */
      |         ^

gcc warns about this:

../wine/dlls/ntdll/unix/virtual.c: In function ‘mmap_add_reserved_area’:
../wine/dlls/ntdll/unix/virtual.c:241:9: error: the comparison will always evaluate as ‘true’ for the pointer operand in ‘(char *)addr + (sizetype)size’ must not be NULL [-Werror=address]
  241 |     if (!((char *)addr + size)) size--;  /* avoid wrap-around */
      |         ^

This reduces the test output to stay within the 32kB limit.

This reduces the test output to stay within the 32kB limit.

This fixes warnings with gcc 12.2.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

This fixes warnings with gcc 12.2.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

(Spotted by warnings emitted by GCC 12.2).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

There's no point in querying this multiple times, it's not going to change.

Perhaps more importantly, calling is_warp_device() inside a todo_wine block
will cause "Test succeeded inside todo block: ..." messages from
get_device_adapter_desc(). These appear to have been introduced by commit
fcc276ec. Arguably get_device_adapter_desc()
shouldn't use ok() in the first place.

d3d11: Implement d3d11_input_layout_to_wined3d_declaration() on top of vkd3d_shader_parse_input_signature().

This was originally prompted by the fact that
wined3d_extract_shader_input_signature_from_dxbc() allocates elements with
HeapAlloc(), but d3d11_input_layout_to_wined3d_declaration() attempts to free
them with free(). That's a regression introduced by commit
b951c37b. Since we're touching the code
though, we may as well use vkd3d_shader_parse_input_signature(), and get rid
of wined3d_extract_shader_input_signature_from_dxbc().

This appears to have gotten lost in commit
7623d0a6.

This fixes an issue exposed (but not caused) by commit
e553be7e. Calling vkFreeCommandBuffers()
after the corresponding command pool was destroyed causes invalid memory
accesses. Thanks to Jacek for pointing this out.

This condition accidentally got inverted when
wined3d_texture_validate_sub_resource_idx() was introduced in commit
44d6f2ad.

This reduces the number of printed todos in order to stay within the 32kB limit.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52677Signed-off-by: Mohamad Al-Jaf <mohamadaljaf@gmail.com>