unicode characters are not printed correctly on the windows command line?
H. S. Teoh
hsteoh at quickfur.ath.cx
Mon Dec 23 15:25:24 UTC 2019
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?
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
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.
And of course, this only applies to Windows. On Posix libc is pretty
much still the standard way of working with console output.
VI = Visual Irritation
More information about the Digitalmars-d-learn