I was writing a project which needed to be UNICODE/ANSI compatible, and the ANSI tests were fine. But then when defining UNICODE and _UNICODE _tprintf(__T("%s"), ...) would only print the first character of the string. I made sure that _tprintf is getting defined as wprintf, and that the string was getting prefixed with L and got the same result. So I made a simple test:
#include <stdio.h>
#include <stdlib.h>
#include <wchar.h>
int main(void)
{
wprintf(L"%s\n", L"Test");
return 0;
}
and again only "T" was printed. I then double checked the MSDN:
Quote
s
String
When used with printf functions, specifies a single-byte–character string; when used with wprintf functions, specifies a wide-character string. Characters are printed up to the first null character or until the precision value is reached.
I then compiled the same project using the Digital Mars C compiler and there was no issue. I believe your implementation of wprintf may be flawed in that it tries to read ANSI strings from %s and since the HIBYTE is 0 on a character like 'T', it ends up terminating the string as the second byte is 0.
Using 5.00.6.
PellesC adheres to the C standard which specifies that %ls must be used to format a widechar string. You can find the info in the help file for format specifiers.
John
Unfortunately for Windows programmers this %s handling is according to standard so it won't be changed guaranteeing us a steady flow of printf complaints. Here are some macros for programs that need to be narrow and wide character under multiple compilers:
http://forum.pellesc.de/index.php?topic=2277.msg8871#msg8871
Generally I appreciate the fact PellesC adheres to the standard and defines compatibility names where necessary, but not in this case. I don't think a series of messy macros is a viable solution for any kind of string formatting, perhaps it's best to use a different compiler when having to deal with UNICODE. Thanks again for clarifying the issue.