C testing framework. ASCII/Unicode portable version

[Alexandre Julliard]

Andriy Palamarchuk <apa3a at yahoo.com> writes:

> If you look even more carefully you'll find that my
> test does not have a single real ASCII character :-P
> Indeed, I do not test text processing there at all. I
> use text strings there for:
> a) identifying registry keys
> b) testing system settings broadcast behaviour
> (comparison against empty string)
> c) tests description

But none of them needs Unicode at all, you would test exactly the same
thing by doing an ASCII only version (ok except maybe the empty string
stuff). And how do you test for instance SystemParametersInfoA sending
a message to a Unicode window proc?  You can't do that with TCHAR.

> b) multibyte, not one-byte characters are the common
> lowest denominator. Converting the test to TCHAR.h I
> had to remember that I'm using multi-byte characters.
> E.g. in some places I needed to replace sizeof(buf) to
> sizeof(buf)/sizeof(_TCHAR).

That's not multi-byte charset support. Multibyte is where you can have
two ASCII bytes represent one character in MBCS codepages. This is
another example where ASCII and Unicode behave differently; so if you
put a multi-byte char in one of the _T("") strings the test will break
for any API that returns a character count.

> We don't use TCHAR in Wine because it does not give us
> any advantages. W and A Wine functions can't exist in
> parallel universes, they must interact, probably
> factor out common behaviour. 
> 
> But I can see which advantages we'll have with using
> TCHAR with wine tests.

Yes of course there are a few advantages. There are also large
inconvenients, which more than offset the small gain IMHO. If your
tests for A and W are identical it's not big deal to write both; and
if they are different at least you can write them without having to
resort to ugly #ifdefs and other hacks.

-- 
Alexandre Julliard
julliard at winehq.com