Nikolay Sivov nsivov@codeweavers.com writes:
On 5/16/19 9:28 PM, Alexandre Julliard wrote:
Nikolay Sivov nsivov@codeweavers.com writes:
Signed-off-by: Nikolay Sivov nsivov@codeweavers.com
dlls/kernelbase/string.c | 34 ++++++++++++++-------------------- 1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/dlls/kernelbase/string.c b/dlls/kernelbase/string.c index 4991ba3fd1..8b3d94a9e6 100644 --- a/dlls/kernelbase/string.c +++ b/dlls/kernelbase/string.c @@ -58,52 +58,46 @@ DWORD WINAPI StrCmpNICW(const WCHAR *str, const WCHAR *cmp, DWORD len) return StrCmpNIW(str, cmp, len); } -BOOL WINAPI IsCharBlankW(WCHAR wc) +static WORD get_char_type(char c) {
- WORD type;
- WORD type = 0;
- GetStringTypeA(GetSystemDefaultLCID(), CT_CTYPE1, &c, 1, &type);
- return type;
+}
- return GetStringTypeW(CT_CTYPE1, &wc, 1, &type) && (type &
C1_BLANK); +BOOL WINAPI IsCharBlankW(WCHAR wc) +{
- return !!(get_char_typeW(wc) & C1_BLANK); } BOOL WINAPI IsCharCntrlW(WCHAR wc) {
- WORD type;
- return GetStringTypeW(CT_CTYPE1, &wc, 1, &type) && (type & C1_CNTRL);
- return !!iscntrlW(wc);
Actually I think it would be preferable to continue using Win32 API functions instead of wine/unicode.h ones. The ultimate goal being to store the character tables in a single place instead of having them accessed directly by multiple dlls.
Kernelbase.dll could be that single place in theory, because it exports GetStringTypeW(). I'm not planning to move kernel32 parts though, not right now.
Yes, we may want to revisit this once kernel32 is implemented on top of kernelbase.