This is a heavily rewritten version of a patch originally by Lorenz
Diener; it was tidied up somewhat by Christian Brabandt, and then
tidied up more by me. The basic idea is to add to the termchar
structure a pair of small structs encoding 24-bit RGB values, each
with a flag indicating whether it's turned on; if it is, it overrides
any other specification of fg or bg colour for that character cell.
I've added a test line to colours.txt containing a few example colours
from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run
the whole of rgb.txt through this treatment, with a command such as
perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
I generated these as a by-product of using afl-fuzz on the testbn
executable. I'd hoped it would find interesting bugs in the bignum
code itself, but in fact it mostly found bugs in the parsing code in
the test main(). However, even so, it did produce a list of tests
which reach as much of the code as afl-fuzz was able to, and that
seems like a useful thing to save.
Also, of course, just having a place to put explicitly specified
bignum tests is a good thing anyway, because then we can put
regression tests on the end of it every time we fix bugs.
I'm about to rewrite the division code, so it'll be useful to have a
way to test it directly, particularly one which exercises difficult
cases such as extreme values of the leading word and remainders just
above and below zero.
mostly so I can valgrind both and make sure they free all their
workspace - a memory leak in this code would be not merely an
inconvenience but a security hazard.
[originally from svn r9101]
testdata/bignum.py is twice the size of the rest of the PuTTY source
put together, so I'm not checking it in.
This reveals bugs in the new multiplication code, which I have yet to
fix.
[originally from svn r9097]
incorrect. I must have written that binary search idiom a hundred
times, so it's rather embarrassing that I can't _automatically_ get
it right! This was causing all kinds of characters to be classified
as ON when they should have been various other classes.
Also while I'm here, I've added another test case to utf8.txt (a
small piece of Arabic within a predominantly L->R line), and also
supplied a means to compile minibidi.c with -DTEST_GETTYPE to
produce a command-line character class lookup tool. (Not sure what
use that'll be _other_ than debugging this precise problem, but I
don't like to throw it away now I've written it :-)
[originally from svn r5016]
going through the line and working out which bits need to be redrawn
is now in a separate loop from the subsequent activity of actually
going through and doing the redraws. This _should_ enable me to
tinker with the which-bits-to-redraw data in between the two, thus
fixing `font-overflow'. However, I thought it would be sensible to
break the work up into two commits so we can track bugs in the
restructuring separately from bugs introduced by the new feature.
Also added a couple more terminal test files.
[originally from svn r5001]