[Vm-dev] Errored: OpenSmalltalk/opensmalltalk-vm#1599 (WIN64_UNICODE - 1f61637)

[Travis CI]

Build Update for OpenSmalltalk/opensmalltalk-vm
-------------------------------------

Build: #1599
Status: Errored

Duration: 42 mins and 8 secs
Commit: 1f61637 (WIN64_UNICODE)
Author: Nicolas Cellier
Message: Handle UTF16 logName and serviceName

These are the last two obstacles that generate compiler warnings with -DUNICODE
No compiler warning does not mean that UNICODE is OK and ready to go.
It means that we have at least eliminated all the trivial TCHAR*/char*/WCHAR* mismatch (and there were a bunch of them!!!)
Also the code is like a battlefield with lot of different ad hoc recipes, that would deserve more uniform approach (refactoring)
But small steps!

To reach the current stage, we have to overhaul printCommandLine()
It can't answer a TCHAR* when sqMain expects a char*argv[]...
So, like what is done in WinMain thru getCommandLineW, we first produce a Wide command line, then convert to UTF8.
There is currently no provision for conversion failure: I don't know how to report and exit when the VM is ran as a service.

Note that command line parsing is then working the other way around: some of the arguments are converted back to UTF16.
I call this style tricotage coding: une maille à l'endroit, une maille à l'envers.
Maybe a deeper change will be to WCHAR* all the way down, but let's differ this decision. Small steps!

Note that another source of problems is RegQueryValueExW.
When we query a WCHAR* string, it is not necessarily NULL terminated.
But every answer is handled as raw un-interpretd-bytes (char *), whose byte length is answered in dwSize.
That's not the WCHAR character length! So buffer[dwSize] = 0 is not the right thing:

- if buffer is declared WVCHAR*, this would write the NULL well beyond the real string length (and eventually overrun the buffer);
- if buffer is declared char*, this would not guaranty a terminating NULL WCHAR (we need 2 zero bytes to make a NULL WCHAR).

Usage of this function will require a careful review, the price of low level API...

Also note that we seem to compile with flag -DNO_SERVICE right now. Why?
I have not enough knowledge in this area and lack tests/examples.
In that conditions, it's not easy to test the modifications! Any help will be greatly appreciated.
The good part is that It won't break current VM usage...
You know what I think of dead-code, but half alive Frankenstein code scares me as well ;)

View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/643a5e3bc031...1f616371ff55

View the full build log and details: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/473863916?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181231/12b1fcf6/attachment.html>