Bug: cpp-terminal crashes if two utf8 are inserted simultaneously

[TobiasWallner]

I have a german keyboard with the 'ö' and 'ä' keys. In utf8 both are 2 bytes long. When I pressed them at the same time accidentally the cpp-terminal crashed. It crashed to such an extend that my terminal closed. I then tried the same not in my application but the kilo editor from the examples. The same thing happened and the kilo editor crashed as well and my terminal closed again. I tried it on the windows cmd terminal and power-shell - same result. But I think it has nothing to do with the terminal, since I can just enter both keys at the same time in the terminal command prompt without trouble .

[flagarde]

@TobiasWallner cpp-terminal is still not full utf8... Could you give me the code you are using? Normally if you press a key that is converted to two or more bytes it should be skip by the software without appearing for now..

Kilo is a bit long code and C to debug.. maybe your code is smaller ^^

[TobiasWallner]

Ahahaha, nah my code is definetly larger. I may find some time to get a minimal example to crash too. Will post it later.

[flagarde]

@TobiasWallner even larger if it's more C++ oriented it would be easier to understand

[certik]

@TobiasWallner thanks for reporting this! Interesting bug. I wonder if somehow the two utf inputs collide. I tried it with a Czech keyboard (ěščřžýýáíé) in the kilo editor, but it doesn't seem to show any of the characters, but also didn't crash. I then tried the multiline prompt, but that didn't work for me at all (#260). I then tried ./minimal, and that works and I can't reproduce this either.

[TobiasWallner]

I have generated a minimal program where the bug appears for me.
You can see it on a branch (utf8_bug_minimal) from my fork of cpp-terminal as an examples program.
Here is the code:
https://github.com/TobiasWallner/cpp-terminal/blob/utf8-bug-minimal/examples/utf8_bug_minimal.cpp

[TobiasWallner]

I only tried it on windows but with GCC, Clang and MSVC. The clang build was the most robust and I had to press 'ö' and 'ä' at the same time a view times before it crashed. GCC and MSVC crashed on the first or second try.

Have not tried it on linux though.

But other key combinations that just use the ASCII representation do not trigger the terminal to crash.

[TobiasWallner]

Also when the terminal crashed, the shell and everything is gone. But when I look in my task manager there is still a running prozess from the just crashed terminal.

[flagarde]

@certik The behaviour you have it's the one expected for now (ěščřžýýáíé) and all utf8 characters should be eaten and not appear on screen (for now). @TobiasWallner The behaviour you see is not expected.

I can have a look but maybe #255 should be merged before to avoid merging problem.

[TobiasWallner]

That is odd, because in my other main application I have no problems reading and displaying utf8 characters with your library when they are being pressed one at a time.

[TobiasWallner]

Also, when I enter utf8 characterd in the kilo editor, it displays them correctly, but there seems to be a bug where the cursor displayed on the screen is being advanced to far. for utf8 characters it advances the cursor by the number of bytes of the utf8 character instead of the number of utf8 complete characters.

[certik]

Probably there are some bugs on Windows regarding utf8.

[flagarde]

Yes windows has always some bug with utf8 even after so many years of trying to do it properly. It's hard to know if it's a library problem or windows problems. I think we should focus on very basic tests for utf8. can you give green light for merging #255 I will then try to code the right stufs to deal with utf8 on terminal input.

Windows is very misleading about UNICODE (utf16) and ANSII which can be turn to utf8 nowdays (maybe with some bugs)

[flagarde]

@TobiasWallner kilo is quite a big program and if I understand correctly was adapted from C code to this library.. Then I modify quite a lot how the library is working so maybe the C/C++ mixing create some problem especially if the program assure or character is one byte etc...

It surely need some polishing but I'm still focusing on the library itselft

[flagarde]

Maybe these big programs could be moved in a bin folder while examples could be used only for small program to emphasis features ? Or to have some basic program for testing. This library is difficult to auto-test so it would be nice to have very simple exmaples that user could use to event test his terminal or to check i everything is fine in his OS like colors or cin