NO

Author Topic: wprintf bug I believe  (Read 2654 times)

RedGhost

  • Guest
wprintf bug I believe
« on: May 01, 2008, 10:40:05 PM »
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:

Code: [Select]
#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.

JohnF

  • Guest
Re: wprintf bug I believe
« Reply #1 on: May 02, 2008, 07:28:32 AM »
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

 

severach

  • Guest
Re: wprintf bug I believe
« Reply #2 on: May 03, 2008, 05:20:11 AM »
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

RedGhost

  • Guest
Re: wprintf bug I believe
« Reply #3 on: May 03, 2008, 01:31:28 PM »
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.