June 2022 - Wine-Devel - list.winehq.org

Re: [PATCH 0/9] MR180: misc: Fixes and workarounds for UAF warnings. (GCC12)

by Esme (＠madewokherd)

Normally I would sign-off the mscoree patch but I don't know how to do that here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/180#note_1564

June 3, 2022

Re: [PATCH v2 0/5] MR131: wined3d: Introduce wined3d_device_check_format_support().

by Jan Sikorski (＠jsikorski)

On Fri May 27 18:11:52 2022 +0000, **** wrote: > Zebediah Figura replied on the mailing list: > ``` > On 5/26/22 01:51, Chip Davis wrote: > > From: Chip Davis <cdavis5x(a)gmail.com> > > > > Signed-off-by: Chip Davis <cdavis5x(a)gmail.com> > > --- > > dlls/wined3d/device.c | 202 ++++++++++++++++++++++++++++++++++++++ > > dlls/wined3d/wined3d.spec | 1 + > > include/wine/wined3d.h | 49 +++++++++ > > 3 files changed, 252 insertions(+) > This doesn't seem like an improvement. I think it potentially makes > sense to use wined3d format information (plus the feature level) to more > accurately match the flags Windows reports—instead of reporting exactly > what the backend is actually capable of—but I don't see a need to move > the whole implementation to wined3d, not when it means adding a lot of > new flags to the API, and not when d3d11 is the only direct user. > Separately, I think changes to the flags we report should be made in a > much more granular fashion, one per commit. Applications can be rather > sensitive to these flags, and I'd rather make any regressions easily > bisectable. > ``` For the record, I agree on the first point, to me it's unclear what the motivation is behind this move. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/131#note_1563

June 3, 2022

Re: [PATCH v3 0/1] MR167: d3drm: IDirect3DRMMeshBuilder3::Load support loading from resource

by Jan Sikorski (＠jsikorski)

I'm really not familiar with this, it does make sense to at least comment why 0xf? I understand it's the | of all FROM flags. Also, should we also error out if there are other flags given (i.e. if (loadflags & ~0xf))? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/167#note_1562

June 3, 2022

[PATCH] include: Allow making Wine Server requests from C++ code

by Mahdi Tayarani

Using SERVER_START_REQ/SERVER_END_REQ in C++ code calls helper methods which need an explicit cast from a void* to __server_request_info*. Signed-off-by: Mahdi Tayarani <tayarani(a)google.com> --- include/wine/server.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/wine/server.h b/include/wine/server.h index b05271b7522..477868c5854 100644 --- a/include/wine/server.h +++ b/include/wine/server.h @@ -70,7 +70,7 @@ static inline data_size_t wine_server_reply_size( const void *reply ) /* add some data to be sent along with the request */ static inline void wine_server_add_data( void *req_ptr, const void *ptr, data_size_t size ) { - struct __server_request_info * const req = req_ptr; + struct __server_request_info * const req = (struct __server_request_info *)req_ptr; if (size) { req->data[req->data_count].ptr = ptr; @@ -82,7 +82,7 @@ static inline void wine_server_add_data( void *req_ptr, const void *ptr, data_si /* set the pointer and max size for the reply var data */ static inline void wine_server_set_reply( void *req_ptr, void *ptr, data_size_t max_size ) { - struct __server_request_info * const req = req_ptr; + struct __server_request_info * const req = (struct __server_request_info *)req_ptr; req->reply_data = ptr; req->u.req.request_header.reply_size = max_size; } -- 2.36.1.255.ge46751e96f-goog

June 3, 2022

Re: [PATCH v2 2/3] jscript: Don't execute any functions if script state does not allow it.

by Jacek Caban

On 6/1/22 15:48, Gabriel Ivăncescu wrote: > On 01/06/2022 03:07, Jacek Caban wrote: >> On 5/31/22 16:56, Gabriel Ivăncescu wrote: >>> Instead of only interpreted functions. Property retrievals or >>> setters are >>> allowed though, as long as they are not accessors. >>> >>> Signed-off-by: Gabriel Ivăncescu<gabrielopcode(a)gmail.com> >>> --- >>> >>> Note that native GetDispID seem to fail when retrieving >>> builtin/prototype >>> functions (?) if script is uninitialized, but retrieving the DISPID >>> before and >>> using it after it's uninitialized still works, though (that's what >>> the tests >>> do). I don't think it's worth replicating this GetDispID quirk for >>> the moment. >> >> >> I'm not really concerned about GetDispID quirks, but implication of >> your choice for the next patch. I think that releasing objects sooner >> is better, so it would be good to have a better argument for moving >> that. Your reasoning there is based on details of how you decided to >> not follow native here. >> >> >> More generally, creating function objects in response for property >> get is an implementation detail that supposed to be transparent. If >> it's causing problems elsewhere, I'd first look at making it more >> transparent. In this case, maybe we should create function objects >> sooner, in response to GetDispID. This would both match all tests and >> allow us to release function constructor sooner. >> >> >> Jacek >> > > Right, but how is releasing such objects not an implementation detail > as well? It's an exposed behaviour, see the attached test. BTW, having tests like that may be nice to catch leaks and test GC in the future. Jacek

June 3, 2022

[PATCH] include: Allow making Wine Server requests from C++ code

by Mahdi Tayarani

June 3, 2022

Re: [PATCH v4 6/6] jscript: Don't allow construction on builtin methods.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

June 3, 2022

Re: [PATCH v4 5/6] jscript: Release all globals when the script is uninitialized.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

June 3, 2022

Re: [PATCH v4 4/6] jscript: Forward actual error in to_primitive if it's not just missing prop.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

June 3, 2022

Re: [PATCH v4 3/6] jscript: Don't execute any functions if script state does not allow it.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

June 3, 2022