Italian Characters: ì ù è à ò cause Segmentation Fault

[littlewing7]

Hi Ross,

I found an issue on how a4 process Italian character that cause a segmentation fault when it is pressed (è,ì,ù,à or ò) :

---

$ Program received signal SIGSEGV, Segmentation fault. stack_chk_fail () at src/env/stack_chk_fail.c:17 17 src/env/__stack_chk_fail.c: No such file or directory. (gdb) bt

0 stack_chk_fail () at src/env/stack_chk_fail.c:17

1 0x000055555556b4df in render_termwin ()

2 0x00007ffff7f2b086 in tickit_bindings_run_event () from /lib/libtickit.so.3

3 0x00007ffff7f391ab in ?? () from /lib/libtickit.so.3

4 0x00007ffff7f39211 in ?? () from /lib/libtickit.so.3

5 0x00007ffff7f39211 in ?? () from /lib/libtickit.so.3

6 0x00007ffff7f39211 in ?? () from /lib/libtickit.so.3

7 0x00007ffff7f3aee1 in tickit_window_flush () from /lib/libtickit.so.3

8 0x00007ffff7f3b08c in ?? () from /lib/libtickit.so.3

9 0x00007ffff7f382d2 in tickit_evloop_invoke_timers () from /lib/libtickit.so.3

10 0x00007ffff7f2c065 in ?? () from /lib/libtickit.so.3

11 0x000055555556c855 in main ()

---

---

a4-keycodes run outside a4 show the character correctly:

but if I run a4-keycode from a4 terminal the Italian ( ì ù à ò è ) character pressed is not showed at all.

can you help me to solve the segmentation fault and correctly show the Italian characters ?

Many thanks

Max

[rpmohn]

Thanks for the detailed report. I can reproduce this and will dig in this weekend.

[rpmohn]

It's all extended ascii chars, so ascii 128-255. a4 can display them, but strips them out when entered in. So, you can open a file with those characters in it and they'll display, but you can't type them in. Working on it.

[rpmohn]

@littlewing7 what is your LANG setting?

[littlewing7]

$ echo $LANG en_US.UTF-8

on the system suffering segFault

[littlewing7]

I tried to install a4 on VOID for ARM64 (musl) and here there aren't SEG-FAULT, but the Italian Char are displayed as

[rpmohn]

I've made debugging progress and am still working on this.

[rpmohn]

Please try the attached patch. The problem was much larger than I at first thought, so thank you for reporting this! Basically, only ASCII characters could be input, no other Unicode at all. The libtickit procedure that reads keyboard input is converting the Unicode code point to UTF-8 encoding, and then that is sent to the libvterm processor, which expects a code point so attempts to again convert its input to UTF-8 encoding, which of course doesn't work. This patch decodes the UTF-8 encoding for Unicode keyboard input before sending it to libvterm for processing. I will look at making this more efficient later, if this tests OK for you.

$ patch <patch_utf8.txt

patch_utf8.txt

[littlewing7]

Hi Ross,

patch tested and work fine

great work!

Max

[rpmohn]

Closing with tag v0.2.2.