lp:~vcs-imports/putty/master

Created by Colin Watson and last modified
Get this branch:
bzr branch lp:~vcs-imports/putty/master

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
VCS imports
Project:
PuTTY
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://git.tartarus.org/simon/putty.git.

The next import is scheduled to run .

Last successful import was .

Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 5 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 20 seconds — see the log

Updating branch...

Launchpad is processing new changes to this branch which will be available in a few minutes. Reload to see the changes.

Recent revisions

6759. By Simon Tatham

Recognise and discard the APC terminal escape sequence.

I encountered an instance of this sequence in the log files from a
clang CI build. The payload text inside the wrapper was
"bk;t=1697630539879"; I don't know what the "bk" stood for, but the
second half appears to be a timestamp in milliseconds since the Unix
epoch.

I don't think there's anything we can (or should) actually _do_ with
this sequence, but I think it's useful to at least recognise it, so
that it can be conveniently discarded.

6758. By Simon Tatham

Further reorganisations of seen_disp_event().

Shortly after the previous commit I spotted another definitely missing
display update: if you send the byte 0x7F, aka 'destructive
backspace', then the display didn't update immediately.

That was two in a row, so I did an eyeball review of the whole
terminal state machine to the best of my ability. Found a couple more
borderline ones, but also, found that the entire VT52 sub-state-
machine had a blanket seen_disp_event which really _shouldn't_ have
been there, because half the VT52 sequences aren't actually display-
modifying updates.

To make this _slightly_ less error-prone, I've sunk a number of
seen_disp_update calls into subroutines that aren't the top-level
term_out(). For example, erase_lots(), scroll(), move() and
swap_screen() now all call seen_disp_update within themselves, so
their call sites don't all have to remember to.

There are probably further bugs after this upheaval, but I think it's
moving in generally the right direction.

6757. By Simon Tatham

Add a missing seen_disp_event for ESC # 3 and friends.

These escape sequences immediately change the display of the line
they're invoked on, so they need to trigger a display update. But they
weren't, and I suppose we must have never noticed before due to the
complete confusion fixed in commit bdbd5f429c79a67.

6756. By Simon Tatham

Tiny fixes in the SOCKS proxy code.

Just happened to jump out at me in an eyeball inspection just now. I
carefully moved all the protocol byte-value constants into a header
file with mnemonic names, but I still hard-coded SOCKS4_REPLY_VERSION
in the text of one diagnostic, and I got the wrong one of
SOCKS5_REQUEST_VERSION and SOCKS5_REPLY_VERSION at one point in the
code. Both benign (the right value was there, juste called by the
wrong name).

Also fixed some missing whitespace, in passing. (Probably the line it
was missing from had once been squashed up closer to the right margin.)

6755. By Simon Tatham

conf.h: improve comments for a couple of options.

6754. By Simon Tatham

Centralise defaults for non-saved options.

These are now specified in conf.h and filled in by automated code,
which means test_conf can make sure we didn't forget to provide them.

The default for a mapping type (not that we currently have any unsaved
ones) is expected to be empty.

Also, while adding test_conf checks, I realised I hadn't filled in the
rest of the comment in conf.h. Belatedly updated that.

6753. By Simon Tatham

Add ability to specify custom load and save separately.

This allows a couple more settings to be treated automatically on
save, which are more complicated on load because they still honour
older alternative save keywords.

In particular, CONF_proxy_type and CONF_remote_qtitle_action now have
explicit enum mappings. These were needed for the automated save code,
but also, I've rewritten the custom load code to use them too. This
decouples the storage format of those settings from the order of
values in the internal enum, which is generally an advantage of
specifying storage enums explicitly.

Those two settings weren't already tested by test_conf, because I
wasn't changing them in previous commits. Now I've added extra code
that does test them, and verified it works when backported to commit
b567c9b2b5e159f where I introduced test_conf before beginning the main
refactoring.

A setting can also be specified explicitly as not loaded and saved at
all. There were quite a few commented that way, but now there's a
machine-readable indication of it.

test_conf will now check that all these settings make sense together -
things shouldn't have a save keyword unless they use it, and should
have one if they don't, and shouldn't specify combinations of options
that conflict.

(For that reason, test_conf is now also running the consistency check
before the main test, so that a missing keyword will cause an error
message _before_ it causes a segfault, saving some debugging!)

6752. By Simon Tatham

Remove spurious 'clipboard' storage enumeration.

It's not used! The only config items that specified it are doing their
load/save in a custom way anyway, and they _don't_ use anything
resembling that enum - instead, they map the integer values in Conf to
strings in the storage format. That enum was a total lie and an
artefact of my conversion macros. Ahem.

6751. By Simon Tatham

test_conf: directly check consistency of conf_key_info.

This is why I wrote conf.h in the form of macros that expanded to
named structure field assignments, instead of just filling it with
named structure field assignments directly. This way, I can #include
the same file again with different macro definitions, and build up a
list of what fields were set in what config options.

This new code checks that if a config option has a default, then the
type of the default matches the declared type of the option value
itself. That's what caught the two goofs in the previous commit.

This is also the part of test_conf that I _won't_ want to delete once
I've finished with the refactoring: it can stay there forever, doing
type checking at test time that the compiler isn't doing for me at
build time.

6750. By Simon Tatham

Fix type mismatches in new conf_key_info.

I suspected there'd be one or two mistakes introduced by that
transcription in spite of the test suite, and there were!

CONF_mouseautocopy had its default labelled as int rather than bool,
because it didn't _look_ boolean to my conversion scripts or to my
eyeballs - but its default value is actually a macro that expands to
'true' or 'false' (depending on platform), so it is really.

And CONF_supdup_ascii_set, conversely, is an int which had its default
labelled as bool, which was due to my conversion scripts faithfully
transcribing the same confusion in the original code.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers