[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] interpret pluginName as UTF8 rather than pure ASCII (98fc85d)

[Nicolas Cellier]

Hmm, no, the terminating NULL should be copied when we pass -1 for original string length.
I think I had to re-read the docs a few times before I convince myself. This part is clear:

> MultiByteToWideChar does not null-terminate an output string if the input string length is explicitly specified without a terminating null character. To null-terminate an output string for this function, the application should pass in -1 or explicitly count the terminating null character for the input string.

Then the result, less so:

> Returns the number of characters written to the buffer indicated by lpWideCharStr if successful. If the function succeeds and cchWideChar is 0, the return value is the required size, in characters, for the buffer indicated by lpWideCharStr.

It's the required size for the **buffer**, in characters, not the number of characters for the string (wcslen), so I understand it is including the terminating NULL, if ever we asked for it (with -1 or with strlen()+1).

To be sure:

    #include <stdio.h>
    #include <windows.h>

    int main() {
        char *foo="foo";
        int len = MultiByteToWideChar(CP_UTF8,0,foo,-1,NULL,0);
        printf("len=%d\n",len);
        return 0;
    }

Then

    $ i686-w64-mingw32-gcc test.c
    $ ./a.exe
    $ len=4


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/98fc85ddd56487492a4988ad457dbc2b3fe88397#commitcomment-31813467
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190101/7cbff128/attachment.html>