Re: [hatari-devel] Warnings

[Vincent Rivière <vincent.riviere@xxxxxxxxxxx>]

On 04/10/2020 à 20:23, Thomas Huth wrote:
> Yes, these two files are from WinUAE ... but at least in readcpu.c it's
> getting kind of ugly, since this is not using "char" but "TCHAR", which
> is a special type on Windows AFAIK, so simply casting to "unsigned
> char" is not appropriate there.

I'm aware of Windows's TCHAR. It is either defined as "char" (ANSI) or 
"unsigned short" (UNICODE). For all standard library functions taking a 
string or character, there is an equivalent macro taking TCHAR arguments.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/isspace-iswspace-isspace-l-iswspace-l

So the TCHAR equivalent of isspace() is _istspace(). Fine.

*But* what I didn't know is that _istspace() suffers of the same issue as 
the warnings we are discussing in Hatari/WinUAE code! Because Microsoft's 
compilers (at least my old VC6) use signed char by default. So, when 
compiling for ANSI, calling _istspace() with a TCHAR argument silently 
returns a bogus value if the TCHAR is actually an accented character! I've 
just tested with VC6: definitely, it doesn't work. This internally produces 
a silent, unnoticed subscript out of range. Reading bogus memory. Wow.

I found the solution in Microsoft CRT sources. Just cast TCHAR to _TUCHAR 
before calling _istspace().

So here is the correct code:

#include <tchar.h>

TCHAR tc = _T('é');
int result = _istspace((_TUCHAR)tc);

I wonder how many software is buggy because of such issue. Probably a lot.

Do what you want with the above. But It would probably useful that the 
WinUAE team have a look regarding to that issue.

> PS: I'm currently experimenting with Cygwin builds on cirrus-ci.com,
> and I can reproduce the compiler warnings there ... I'll add a
> regression test job to our .cirrus-ci.yml once I've got it in a proper
> shape.

Very good.

--
Vincent Rivière