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/98fc85ddd56487492a…
Sorry for the recent build noise.
There is a persistent build failure I was trying to have a look at...
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/333
I don't know how to build ARM locally, so I was iterating on the CI builds.
I'd configured travis.yml to direct the noise to just my email...
https://github.com/bencoman/opensmalltalk-vm/blob/issue333-broken-arm-build…
but forgot about appveyor. I'll fix it for future iterations.
I'm nearly at the end of my capability with this. Anyone that can help out
would be appreciated. Its no good to let this failed build job persist.
cheers -ben