unicode characters are not printed correctly on the windows command line?

Steven Schveighoffer schveiguy at gmail.com
Mon Dec 23 15:41:33 UTC 2019


On 12/23/19 10:25 AM, H. S. Teoh wrote:
> On Sun, Dec 22, 2019 at 10:04:20PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> [...]
>> Regardless, I'm pretty well of the opinion that fwrite is the wrong
>> thing to do anyway. fwrite writes bytes to a file, but we want to
>> write strings to the console. There's other functions that do that.
> [...]
> 
> Would it make sense for std.stdio.write* (the package global functions,
> as opposed to File.write*) to use the Windows console output functions
> instead of proxying to libc?

That means we have to buffer separately, which means we have a problem 
interleaving printf with writef. It would be awful.

> Alternatively, we could change std.stdio.File to check if the current
> file descriptor is the console (fd == stdout && stdout == console,
> however you figure that out in Windows), and silently switch to the
> Windows console output functions instead of libc.  We *are* already
> wrapping libc's FILE*, why not wrap the Windows console output functions
> as well.

Again, the docs say you have to use wprintf, not fwrite. We would have 
to switch to using wprintf, and I'm not sure it's very easy thing to do. 
It might be possible though.

> 
> Mixing raw libc printf with std.stdio.write* is a bad idea anyway; do we
> really need to support that??  Though calling fflush(stdout) may not be
> amiss, just to alleviate sudden breakage and ensuing complaints.

There's this guy, his name is Walter. He likes printf. I'm pretty sure 
when he's buried, his cold dead fingers will be tightly and inextricably 
wrapped around printf.

> And of course, this only applies to Windows. On Posix libc is pretty
> much still the standard way of working with console output.

The source of this thread is for valid unicode to come out on the 
screen, which I'm pretty sure Posix systems support just fine.

Other than that, there are good reasons NOT to use libc, but this is 
disruptive and difficult to get right as a "drop in"

-Steve


More information about the Digitalmars-d-learn mailing list