[Vm-dev] the warnPrintf dilemna

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Jan 4 21:47:19 UTC 2019


Le ven. 4 janv. 2019 à 12:35, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> 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?
>
>
These small steps will guide me for the immediate problem:
- 1) have all warnPrintf defined as taking a char * so as to be uniform
across platforms and compatible with minheadless
- 2) provide a warnPrintfW (and warnPrintfT macro for UNICODE agnostic
code) for the rare cases that may require Wide char
- 3) define warnPrintfW/T in minheadless too, somewhere in the windows
specific headers (it can be simply defined as wprintf)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190104/8d7451cd/attachment.html>


More information about the Vm-dev mailing list