simon-git: putty (pre-0.77): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  01d85614 do_bidi: initialise paragraphOverride correctly.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: pre-0.77
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2022-05-24 17:55:51

commit 01d85614464a8405a427669b73142c281f3a7faf
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=01d85614464a8405a427669b73142c281f3a7faf;hp=e06a3dda4505dfd0fdeec5b183f21e79e13da0d1
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue May 24 17:43:48 2022 +0100

    do_bidi: initialise paragraphOverride correctly.
    
    I'd forgotten to initialise it at all, which meant it was set to zero
    by the initial memset of the whole BidiContext on creation. But in our
    enumeration of bidi character types, zero corresponds to L (the most
    common left-to-right alphabetic character class), and as a value for
    paragraphOverride, that is not neutral.
    
    As a result, a command such as this (assuming UTF-8)
    
      echo -e '\xD7\x90\xD7\x91'
    
    would produce Hebrew aleph and beth in the correct display order
    (aleph on the right), but aligned to the left margin of the terminal
    instead of the right margin, because the overall direction of the line
    was taken to be forcibly overridden to "left-to-right" instead of
    being inferred dynamically from the line contents.
    
    do_bidi() is a tiny wrapper on the inner function that does all the
    real work. And the inner function has been subjected to the whole
    Unicode 14 bidi conformance test. So naturally, the "trivial" but
    untested function just outside it is where the embarrassing bug was.

 terminal/bidi.c | 1 +
 1 file changed, 1 insertion(+)