bugGNU nano - Bugs: bug #50899, without UTF-8, nano aborts in...

 
 

bug #50899: without UTF-8, nano aborts in French

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Sun 30 Apr 2017 09:44:36 AM UTC  
 
Severity: 5 - BlockerStatus: Fixed
Assigned to: Benno Schulenberg <bens>Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 05 May 2017 09:24:07 AM UTC, comment #8:

Fix was released in 2.8.2.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Thu 04 May 2017 09:44:51 AM UTC, comment #7:

Sorry for the noise then :)

Egmont Koblinger <egmont>
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.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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!

Egmont Koblinger <egmont>
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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!

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by egmont (Posted a comment)
  • -unavailable- added by bens (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 05 May 2017 09:24:07 AM UTCbensOpen/ClosedOpen=>Closed
    Sun 30 Apr 2017 11:02:43 AM UTCbensStatusIn Progress=>Fixed
    Sun 30 Apr 2017 10:33:42 AM UTCbensStatusNone=>In Progress
      Assigned toNone=>bens

    Back to the top


    Powered by Savane 3.1-cleanup1