Fri 05 May 2017 09:24:07 AM UTC, comment #8:
Fix was released in 2.8.2.
|
Thu 04 May 2017 09:44:51 AM UTC, comment #7:
Sorry for the noise then :)
|
Thu 04 May 2017 08:58:06 AM UTC, comment #6:
> As far as I understand, this is supposed to be an upper cap on
> the factor between the visible width (cell in the terminal) and
> the string length in bytes?
No, MAXCHARLEN has nothing to do with visible width. It is just the maximum amount of bytes that a single codepoint can occupy. (I'm a bit surprised that glibc sets MB_CUR_MAX to 6 -- valid UTF-8 sequences are at most 4 bytes long, no?)
(The problem noted in this bug did not appear when using UTF-8, because then nano reserved 96 bytes (16 * MAXCHARLEN) for the shortcut keystrokes, to be ready for the worst case, while in fact it would typically use just 9 or 10 bytes. This gave translations of the shortcut description some 85 bytes of "breathing" space, to be longer than the English original. That was more than enough for all locales -- except Ukrainian.)
|
Wed 03 May 2017 09:29:07 PM UTC, comment #5:
> when using UTF-8, the MAXCHARLEN of 6 gives more than enough slack for all translations to fit
As far as I understand, this is supposed to be an upper cap on the factor between the visible width (cell in the terminal) and the string length in bytes?
If so, please keep in mind that this formula does not count for combining characters!
|
Sun 30 Apr 2017 11:38:57 AM UTC, comment #4:
About why 45f873a6 seemd to be the offending commit: it printed some extra keys (Ins, Del, Enter...), taking up some forty extra bytes, which apparently was just enough to push the French and Dutch translations over the edge. But the "verbose" German translation (de), for example, already made nano-2.3.6 abort.
|
Sun 30 Apr 2017 11:02:43 AM UTC, comment #3:
The basic problem is present since at least bd2c8f3d in June 2006. But in those days three columns of keys were shown, for which 24 chars were reserved, but in fact for most of the third columns a single tab was used, so this gave some slack so that the description translations could be a bit longer than the English ones without transgressing the reserved space -- except for Ukranian: because of its different script, it uses /far/ longer strings.
And, of course, when using UTF-8, the MAXCHARLEN of 6 gives more than enough slack for all translations to fit, even when they are quite a bit longer than the English original.
Fixed in git, 395c8e9e.
|
Sun 30 Apr 2017 10:33:42 AM UTC, comment #2:
Hrrm... How can the offending commit be 45f873a6 when the released version 2.4.3 itself (nearly three months later) is still fine? Because... the PO files weren't updated until 2.5.0?
Hmmm... Computation of the length of the description of each shortcut happens over the untranslated shortcut... Boooo!
|
Sun 30 Apr 2017 10:21:54 AM UTC, comment #1:
The offending commit is 45f873a6.
In fact, it aborts in several languages: de, es, fr, nl... But not in en, eo, fi, hr, tr... In Ukranian (uk), though, it is even worse: it segfaults.
|
Sun 30 Apr 2017 09:44:36 AM UTC, original submission:
To reproduce, configure nano with --disable-utf8, compile, and
then run:
LANGUAGE=fr src/nano
and type: ^G ^X. Result: Aborted.
Valgrind says nano does a few invalid writes in help_init(), and then a bunch of invalid reads. It allocates a block on 5400 bytes, and then trangresses that block by /just/ a couple of bytes -- eleven at maximum. Somehow we miscompute how many bytes the written-out help text needs.
Bug is present since nano-2.5.0.
|