mixed narrow and wide-char output only produce first used.

[adamyg]

When mixed ansi/narrow and wide-char clib output primitives are used under OWC only the first interface produces output compared to both for MSVC built application.

Understand this may be undefined behavior, yet target (win32/64) consistently should be considered. CRT Unicode stream I/O

Examples:

When built with OWC only "hello world\n" shall be produced, whereas both "hello world\n" and "whello world\n" are produced under MSVC.

#include <stdio.h>
int
main()
{
    printf("hello world\n");
    wprintf(L"whello world\n");
    return 0;
}

When built with OWC only "whello world\n" only shall be produced, whereas both "whello world\n" and "hello world\n" are produced under MSVC.

#include <stdio.h>
int
main()
{
    wprintf(L"whello world\n");
    printf("hello world\n");
    return 0;
}

[jmalak]

Thanks for your bug report.
I can reproduce it.
It looks like bug in CRTL.

[jmalak]

It looks like it is realated to mistake in use of "stream orientation" feature.
Anyway it should not remove output.

[jmalak]

it looks like the C standard doesn't specify behaviour for such situation, also it is not specified as undefined behaviour.
It stated only
"Byte input/output functions shall not be applied to a wide-oriented stream and wide
character input/output functions shall not be applied to a byte-oriented stream."
I deduce it is undefined behaviour that what happen is implementation defined.
OW suppress such incompatible output. May be we could output somehow, but anyway it will be wrong, strange behaviour.

[adamyg]

Comparison:

• mingw64 - both are produced.
• cygwin - only one is produced.

[jmalak]

For US ASCII or Latin-1 character set it is possible for most of characters because value of single-byte and UNICODE characters are same, but for other character sets it is not true and it can result in some crashes etc.
OW solution is safe even if it looks like a bug.