[PATCH v2 4/6] ntdll: Expose ntdll_check_buffer_for_read and ntdll_check_buffer_for_write to Unix libs.

[Jacek Caban]

On 10/5/21 9:04 PM, Alexandre Julliard wrote:
> Jacek Caban <jacek at codeweavers.com> writes:
>
>> On 10/5/21 7:56 PM, Alexandre Julliard wrote:
>>> Jacek Caban <jacek at codeweavers.com> writes:
>>>
>>>> Signed-off-by: Jacek Caban <jacek at 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