Signed-off-by: Jacek Caban jacek@codeweavers.com --- dlls/ntdll/unix/file.c | 6 +++--- dlls/ntdll/unix/socket.c | 2 +- dlls/ntdll/unix/unix_private.h | 2 -- dlls/ntdll/unix/virtual.c | 16 ++++++++-------- include/wine/unixlib.h | 2 ++ 5 files changed, 14 insertions(+), 14 deletions(-)
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
dlls/ntdll/unix/file.c | 6 +++--- dlls/ntdll/unix/socket.c | 2 +- dlls/ntdll/unix/unix_private.h | 2 -- dlls/ntdll/unix/virtual.c | 16 ++++++++-------- include/wine/unixlib.h | 2 ++ 5 files changed, 14 insertions(+), 14 deletions(-)
Is that one also meant to be temporary? That sort of thing should be handled by the syscall exception handling.
On 10/5/21 7:56 PM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
dlls/ntdll/unix/file.c | 6 +++--- dlls/ntdll/unix/socket.c | 2 +- dlls/ntdll/unix/unix_private.h | 2 -- dlls/ntdll/unix/virtual.c | 16 ++++++++-------- include/wine/unixlib.h | 2 ++ 5 files changed, 14 insertions(+), 14 deletions(-)
Is that one also meant to be temporary? That sort of thing should be handled by the syscall exception handling.
I originally solved it with the attached patch (it would need to be changed for _NTSYSTEM_/WINE_UNIX_LIB), does something like that look better? I changed it because I noticed that ntdll uses virtual_check_buffer_for_* instead. Default syscall exception behaviour of returning exception code is not enough in those cases (convert_bitmapinfo callers need to do cleanup and we have a test that NtGdiAddFontMemResourceEx returns 0, not an exception code).
Thanks,
Jacek
Jacek Caban jacek@codeweavers.com writes:
On 10/5/21 7:56 PM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
dlls/ntdll/unix/file.c | 6 +++--- dlls/ntdll/unix/socket.c | 2 +- dlls/ntdll/unix/unix_private.h | 2 -- dlls/ntdll/unix/virtual.c | 16 ++++++++-------- include/wine/unixlib.h | 2 ++ 5 files changed, 14 insertions(+), 14 deletions(-)
Is that one also meant to be temporary? That sort of thing should be handled by the syscall exception handling.
I originally solved it with the attached patch (it would need to be changed for _NTSYSTEM_/WINE_UNIX_LIB), does something like that look better? I changed it because I noticed that ntdll uses virtual_check_buffer_for_* instead. Default syscall exception behaviour of returning exception code is not enough in those cases (convert_bitmapinfo callers need to do cleanup and we have a test that NtGdiAddFontMemResourceEx returns 0, not an exception code).
Yes, I think a real exception handler would be better.
Note that ntdll uses virtual_check_buffer* only when the buffer is passed to a server call, since that doesn't trigger an exception; it's not something we want to use in general. Triggering an actual exception and handling it is preferable.
On 10/5/21 9:04 PM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
On 10/5/21 7:56 PM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
dlls/ntdll/unix/file.c | 6 +++--- dlls/ntdll/unix/socket.c | 2 +- dlls/ntdll/unix/unix_private.h | 2 -- dlls/ntdll/unix/virtual.c | 16 ++++++++-------- include/wine/unixlib.h | 2 ++ 5 files changed, 14 insertions(+), 14 deletions(-)
Is that one also meant to be temporary? That sort of thing should be handled by the syscall exception handling.
I originally solved it with the attached patch (it would need to be changed for _NTSYSTEM_/WINE_UNIX_LIB), does something like that look better? I changed it because I noticed that ntdll uses virtual_check_buffer_for_* instead. Default syscall exception behaviour of returning exception code is not enough in those cases (convert_bitmapinfo callers need to do cleanup and we have a test that NtGdiAddFontMemResourceEx returns 0, not an exception code).
Yes, I think a real exception handler would be better.
OK, I will prepare a new patch.
Note that ntdll uses virtual_check_buffer* only when the buffer is passed to a server call, since that doesn't trigger an exception; it's not something we want to use in general. Triggering an actual exception and handling it is preferable.
Oh, I see, that's different.
Thanks,
Jacek