If function _io__WindowsConsoleIO_write_impl does not produce as expected output from WriteConsoleW, it is the process of recalculating the existing len.
At this point, function WideCharToMultiByte finds the byte length of utf-8 and function MultiByteToWideChar finds the letter length of utf-16. And is this comparison valid for comparing the results of these two?
This is apparently code that I wrote (many years ago), but I don’t recall it, and the whole quoted block seems like a weird thing to be doing.
Basically, for those who haven’t clicked through to read the whole function, write(b) is only allowed a single system call, and if that call doesn’t write the entire buffer it has to return the number of bytes that were actually written. winconsoleio converts back into Unicode to write it out. At this point, the n < wlen means that fewer (UTF-16) characters were written than were in the buffer, and so we should be recalculating the number of bytes that were actually used to return (in len).
An assert that would probably make sense here would be to check the new wlen against n, to verify that the amount of data we’re saying was used is able to round-trip through the UTF-8->UTF-16 conversion. Comparing to len is correct if the buffer only contains single-byte characters, which we have no way of knowing here.
But checking the length a second time doesn’t really seem necessary. Updating len with the WideCharToMultiByte result here should be enough I think. Lines 1057-1061 aren’t necessary.
I’ll create a PR right away then
It looks to me that the intented assert is wlen == n.