[Vm-dev] the warnPrintf dilemna

[Nicolas Cellier]

So I have made good progress in making Win32/64 VM -DUNICODE compatible.
minheadless VM already uses -DUNICODE, so all should go well... but...

But now I have some conflicts with minheadless VM.
- minheadless defines warnPrintf as printf (thus taking a char *)
- regular platforms/win32/vm defines it as taking a TCHAR*

it did before me, I did not change it, I just made sure that every sender
would provide a TCHAR* thru TEXT() macro. By fixing platforms/win32/plugins
for -DUNICODE compatibility, I thus broke win32 minheadless

The problem is not completely blocking: we can just ignore compiler
warnings for the moment. Then if the plugin are verbose, the output will be
truncated or garbled...

But if we are serious, then we need to unify.
The question is what are the expectations concerning error/warning outputs?
The windows console do handle UTF16 (WCHAR).
But maybe we don't want to output to console?

Another consideration:
- if warnPrintf is used in paltforms/Cross then its signature MUST NOT
change from one architecture to another. Before minheadless, it was not
used in Cross.
- if warnPrintf is used in several platforms/specific_arch it may take
different signatures... but it should rather not, because this is dangerous
for us programmers: the risk of making a mistake grows high, the ability to
easily review code changes drops down. That's unfortunately the case.

For the case of different signatures, I would be inclined to have different
names.

We also have printLastError in windows... which is like perror on Unix, but
takes a TCHAR*
DPRINTF for debug purposes which may take many different forms, including
warnPrintf.
DBGPRINTF same.
And plenty of direct usage of printf perror...

There are basically two points of view:
- all these functions are services provided by the VM. A plugin should not
decide to bypass the VM and directly call underlying OS low level
functions. We should then try to officialize those services
- we stick to standard IO stdin stdout stderr paradigm (which might
naturally be the point of view of a minheadless VM), but then what about OS
conventions like encoding?

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190104/b32d3231/attachment.html>