Dan Kegel dank@kegel.com writes:
Next patch will expose them for msvcr100.
From 357c45971e1315e8f6cd1f9feac65cf96a006a41 Mon Sep 17 00:00:00 2001 From: Dan Kegel dank@kegel.com Date: Fri, 20 Jul 2012 10:39:32 -0700 Subject: [PATCH 1/2] msvcrt: add wmemcpy_s and wmemmove_s
dlls/msvcrt/heap.c | 29 ++++++++++++++++++++++++ dlls/msvcrt/msvcrt.spec | 2 + dlls/msvcrt/tests/misc.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 85 insertions(+), 0 deletions(-)
You shouldn't need to put that in msvcrt. Also please check the parameters correctly like every other _s function does.
On Mon, Jul 23, 2012 at 5:56 AM, Alexandre Julliard julliard@winehq.org wrote:
You shouldn't need to put that in msvcrt.
OK, I'll put it in msvcr90.
Also please check the parameters correctly like every other _s function does.
The wmemmove_s/wmemcpy_s I posted are exact copies of the existing non-w implementation. I was assuming the only change needed was to use wide chars instead of bytes. Does the existing memmove_s also need fixing? Are you referring to using MSVCRT_CHECK_PMT()?
Dan Kegel dank@kegel.com writes:
On Mon, Jul 23, 2012 at 5:56 AM, Alexandre Julliard julliard@winehq.org wrote:
You shouldn't need to put that in msvcrt.
OK, I'll put it in msvcr90.
It's not supposed to be there either.
Also please check the parameters correctly like every other _s function does.
The wmemmove_s/wmemcpy_s I posted are exact copies of the existing non-w implementation. I was assuming the only change needed was to use wide chars instead of bytes. Does the existing memmove_s also need fixing? Are you referring to using MSVCRT_CHECK_PMT()?
Yes, and the existing ones may need fixing too. This needs test cases.
On Mon, Jul 23, 2012 at 8:33 AM, Alexandre Julliard julliard@winehq.org wrote:
You shouldn't need to put that in msvcrt.
OK, I'll put it in msvcr90.
It's not supposed to be there either.
Maybe I was grepping without the w prefix by accident, sorry. I see now it's only in msvcr100. - Dan
-
Alexandre Julliard -
Dan Kegel