No output mixing wprintf & printf (v8 rc4)

[aMarCruz]

Hi Pelle,
mixing wprintf/printf generate no output for wprintf.

Code: [Select]

// mixprintf.c
#include <stdio.h>
#include <wchar.h>
int main(void)
{
    printf("char\n");
    wprintf(L"wchar_t\n");
    printf("done.\n");
    return 0;
}

Compile: cc mixprintf.c
Output:

char
done.


if you compile with /D_UNICODE the output is the same.

@beto

[jj2007]

When debugging with Olly, it seems that the two ANSI strings get displayed via WriteFile to Conout$; the Unicode string never reaches that call...

If, however, you disable the first ANSI printf, you will see only Unicode; which might point to an invalid handle problem. Without the first ANSI printf, the wprintf call ends up at WriteFile call, but with an ANSI string. At least, Olly believes it is ANSI, although it's probably UTF-8.

With other languages it is possible to mix ANSI and Unicode - these lines are copied from a console window, and only the first and last line use the equivalent of printf():

Welcome
Добро пожаловать
مرحبا بكم
歡迎
Welcome

[aMarCruz]

I see.
With Clang, MinGW, MSVC 2003/2010 the output is correct.

Thanks.
@beto

[frankie]

Seems to be an old problem of PellesC since V4.5 and before, the first printf family used qualify the output type more or less. If you use printf as first output all the subsequent wprintf, and the like, don't work.
Maybe it's time to start working on console code...

[Pelle]

Not a bug. Each stream has an orientation: byte-oriented or wide-oriented. See fwide().

[jj2007]

Not a bug. Each stream has an orientation

Then you should open two streams. If I can mix them arbitrarily in assembler, as shown above, it should be possible in C, too.

[frankie]

MS doesn't implement fwide see.
The strict adherence to C11 standard is one of the cause of incompatibility with MS and other (i.e. MingW) on console output.
I don't want critizice the choose, but a compiler that is only targeted on MS OS's (that has a well known messed up console I/O) adhering so strictly maybe makes not very friendly the use of stdio functions...

[jj2007]

Lousy workaround:

#include <stdio.h>
#include <windows.h>
#include <wchar.h>

void aprintf(char *c) {
   unsigned long int byteswritten;
    WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), c, strlen(c), &byteswritten, 0);
}

int main(void)
{
  wprintf(L"Unicode print\n");
  aprintf("Ansi print");
  wprintf(L"\nUnicode again\n");
  return 0;
}

[frankie]

Yes JJ,
the only solution seems to be to write an IO subsystem that directly writes to console and allow the use MS or MingW like codepage translation.
A little modification to your code:

Code: [Select]

#include <stdio.h>
#include <windows.h>
#include <wchar.h>

void __cdecl aprintf(char *format, ...) {
   char buff[8192];    //Large enoug? WARNING: not thread safe 
   va_list va;
   va_start(va, format);
   _vsnprintf(buff, 8191, format, va);
   va_end(va);         //For correctness as pointed out by John
   //Here we should put translation for codepage...
   unsigned long int byteswritten;
   WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buff, strlen(buff), &byteswritten, 0);
}

int main(void)
{
  wprintf(L"Unicode print\n");
  aprintf("Ansi print");
  wprintf(L"\nUnicode again\n");
  return 0;
}
Modify message


[JohnF]

Shouldn't that have a va_end() at the end of that function, or has it been depreciated.

John

[frankie]

Shouldn't that have a va_end() at the end of that function, or has it been depreciated.

John

Yes, yuo're right, but I just wrote it as a fast example.
Anyway va_end just assign a NULL value to the args pointer here, maybe on different machines it can create complications...

[frankie]

I took a look to MingW crt, it is just a wrapper for msvcrt.
So in MingW what works for MS works for it.