Aleksey Bragin <aleksey(a)reactos.org> writes:
> diff --git a/server/class.c b/server/class.c
> index 0e402ba..90ab436 100644
> --- a/server/class.c
> +++ b/server/class.c
> @@ -47,6 +47,7 @@ struct window_class
> int local; /* local class? */
> atom_t atom; /* class atom */
> mod_handle_t instance; /* module instance */
> + user_handle_t background; /* background brush handle */
> unsigned int style; /* class style */
> int win_extra; /* number of window extra bytes */
> client_ptr_t client_ptr; /* pointer to class in client address space */
Brushes are not user handles, and it doesn't make much sense to share
them since the handles are process-local currently.
--
Alexandre Julliard
julliard(a)winehq.org
Hi,
Alexandre Julliard wrote:
>> it needs to be "foo[]". ANYSIZE_ARRAY is defined as 1
>True, you don't want to change the public one, but you can define a
>shell32-specific version of it. At least then it looks like a normal
>array declaration.
Thank you for pointing to ANYSIZE_ARRAY.
Why not cope with the way MS people recommend and use
foo[ANYSIZE_ARRAY], together with the FIELD_OFFSET() macro?
I found this article useful:
http://blogs.msdn.com/b/oldnewthing/archive/2004/08/26/220873.aspx
and made a note to use that in future patches.
It explains why ANYSIZE_ARRAY MUST be 1.
Should somebody submit patches to replace foo[1] with foo[ANYSIZE_ARRAY]
where needed in Wine's include/*.h ?
E.g. wingdi.h: BITMAPINFO comes to mind, it uses
RGBQUAD bmiColors[1];
http://source.winehq.org/source/include/wingdi.h#L1912
ANYSIZE_ARRAY would be a perfect match here.
Perhaps one can teach fortify about ANYSIZE_ARRAY?
Regards,
Jörg Höhle
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=5346
Your paranoid android.
=== W2KPROSP4 (32 bit install) ===
Timeout
=== WXPPROSP3 (32 bit install) ===
Timeout
2010/9/19 Łukasz Wojniłowicz <lukasz.wojnilowicz(a)gmail.com>:
> +/*
> + * IP configuration utility
> + * English language support
> + *
Pedantically, that should probably be "Polish language support".
Trying to build Wine on a new tester which initially had too few packages
installed I ran into the following.
In file included from bitblt.c:33:
x11drv.h:30:22: error: X11/Xlib.h: No such file or directory
x11drv.h:31:27: error: X11/Xresource.h: No such file or directory
x11drv.h:32:23: error: X11/Xutil.h: No such file or directory
x11drv.h:33:23: error: X11/Xatom.h: No such file or directory
x11drv.h:44:21: error: X11/Xmd.h: No such file or directory
x11drv.h:45:24: error: X11/Xproto.h: No such file or directory
Indeed include/config.h has HAVE_X11_XLIB_H undefined since, well, all
these headers indeed are missing.
On the other hand, configure did not halt. In fact, configure did not
even warn about this situation unlike it does in other cases.
How to fix this?
Should dlls/winex11.drv just not be built in such a case? Should
configure error out? (We do have --without-x, too, though.) Anything
else?
Currently we do pass configure and then run into a compile failure
later on.
Gerald
"Vincent Povirk" <vincent(a)codeweavers.com> writes:
> Fixed the pollfds leak from try 1.
You are still leaking the file descriptors.
--
Alexandre Julliard
julliard(a)winehq.org
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=5328
Your paranoid android.
=== W2K8SE (32 bit url) ===
url.c:1337: Test failed: unexpected call OnProgress_SENDINGREQUEST
Gerald Pfeifer <gerald(a)pfeifer.com> writes:
> @@ -388,6 +388,8 @@ static int DIB_GetBitmapInfo( const BITMAPINFOHEADER *header, LONG *width,
> *compr = header->biCompression;
> return 1;
> }
> +
> + *width = *height = 0;
> ERR("(%d): unknown/wrong size for header\n", header->biSize );
> return -1;
> }
0 is not valid for a bitmap, these should never be used in the error
case.
--
Alexandre Julliard
julliard(a)winehq.org