[Sbcl-devel] win32-foreign-load encoding patch
20 views
Skip to first unread message
Dmitry Ignatiev
Oct 13, 2023, 5:43:14 PM10/13/23
to sbcl-devel
win32-foreign-load.lisp:
(define-alien-routine ("LoadLibraryA" loadlibrary) hinstance
(file c-string))
Shouldn't this be replaced by LoadLibraryW and :utf-16le c-string? That would correctly handle non-ASCII paths.
IIRC c-string without format specifier uses :UTF-8, which is not what 'A' functions expect(those expect CP_ACP, which is an alias to the current system-specific locale, say CP1251 in case of russian localization)
Also, GetModuleHandleW defined below in the same file should have :external-format of :utf-16le instead of :ucs-2. `W' functions expect UTF-16/LE.
As for the GetProcAddress - it also uses CP_ACP(and does not have a unicode(i.e. `W') version), but in whole my life I've never encountered a single DLL that had an exported function that used non-ASCII characters. Those may exist, but handling CP_ACP would require handling all possible Windows ANSI code pages. So the solution is to limit function names to ASCII characters.
Patch attached.
(define-alien-routine ("LoadLibraryA" loadlibrary) hinstance
(file c-string))
Shouldn't this be replaced by LoadLibraryW and :utf-16le c-string? That would correctly handle non-ASCII paths.
IIRC c-string without format specifier uses :UTF-8, which is not what 'A' functions expect(those expect CP_ACP, which is an alias to the current system-specific locale, say CP1251 in case of russian localization)
Also, GetModuleHandleW defined below in the same file should have :external-format of :utf-16le instead of :ucs-2. `W' functions expect UTF-16/LE.
As for the GetProcAddress - it also uses CP_ACP(and does not have a unicode(i.e. `W') version), but in whole my life I've never encountered a single DLL that had an exported function that used non-ASCII characters. Those may exist, but handling CP_ACP would require handling all possible Windows ANSI code pages. So the solution is to limit function names to ASCII characters.
Patch attached.
Best regards,
Dmitry
Dmitry Ignatiev
Oct 13, 2023, 6:28:04 PM10/13/23
to sbcl-devel
P.S. Other uses of :ucs-2 in the context of `WhateverW' functions should also be replaced with :utf-16le. ANSI strings, on the other hand, could probably be handled using WideCharToMultiByte in the generic case but that would require double conversion (i.e. from lisp strings(which are UTF-32 IIRC) to UTF-16/LE and then to ANSI code page using WideCharToMultiByte) and that is also subject to a data loss unless WC_ERR_INVALID_CHARS flag is used.
P.P.S. Windows build should always include :SB-UNICODE, it does not make any sense to use a non-unicode version on Windows.
Best regards,
Dmitry
сб, 14 окт. 2023 г. в 00:42, Dmitry Ignatiev <loves...@gmail.com>:
Wilfredo Velazquez
Oct 13, 2023, 9:47:21 PM10/13/23
to Dmitry Ignatiev, sbcl-devel
Just chiming in that yes, any modern (last 10+ years) on Windows should pretend the 'A' versions of all the win32 functions should be generally considered deprecated. They all coerce their string to ucs2 and all the 'W' versions anyway.
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Wilfredo Velázquez-Rodríguez
Reply all
Reply to author
Forward
0 new messages