New hostname-handling functions in misc.c.

These are intended to make it easier to handle strings of the form
"hostname:port" or other colon-separated things including hostnames
(such as the -L and -R command-line option arguments), even though the
hostname part might be a square-bracketed IPv6 address literal
containing colons that have to _not_ be treated as separating the
top-level string components.

Three of these functions have semantics as much like existing C
library functions as I could make them (host_strchr, host_strrchr,
host_strcspn) so that it wouldn't be too error-prone to replace
existing C functions with them at lots of call sites. The fourth
function (host_strduptrim) just strips square brackets off anything
that looks like an IPv6 literal.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10119 cda61777-01e9-0310-a592-d414129be87e
Use the new host_str* functions to improve IPv6 literal support.

I've gone through everywhere we handle host names / addresses (on
command lines, in PuTTY config, in port forwarding, in X display
names, in host key storage...) and tried to make them handle IPv6
literals sensibly, by using the host_str* functions I introduced in my
previous commit. Generally it's now OK to use a bracketed IPv6 literal
anywhere a hostname might have been valid; in a few cases where no
ambiguity exists (e.g. no :port suffix is permitted anyway)
unbracketed IPv6 literals are also acceptable.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10120 cda61777-01e9-0310-a592-d414129be87e
Avoid misidentifying unbracketed IPv6 literals as host:port.

Both GUI PuTTY front ends have a piece of logic whereby a string is
interpreted as host:port if there's _one_ colon in it, but if there's
more than one colon then it's assumed to be an IPv6 literal with no
trailing port number. This permits the PuTTY command line to take
strings such as 'host', 'host:22' or '[::1]:22', but also cope with a
bare v6 literal such as '::1'.

This logic is also required in the two Plink front ends and in the
processing of CONF_loghost for host key indexing in ssh.c, but was
missing in all those places. Add it.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10121 cda61777-01e9-0310-a592-d414129be87e
Support explicit IPv6 source addresses in Windows port forwarding.

There's been a long-standing FIXME in Windows's sk_newlistener which
says that in IPv6 mode, an explicit source address (e.g. from a
command-line option of the form -L srcaddr:12345:dest:22) is ignored.
Now it's honoured if possible.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10122 cda61777-01e9-0310-a592-d414129be87e
Fix a potential crash in ssh_setup_portfwd.

If we search for a colon by computing ptr + host_strcspn(ptr,":"),
then the resulting pointer is always non-NULL, and the 'not found'
condition is not !p but !*p.

This typo could have caused PuTTY to overrun a string, but not in a
security-bug sense because any such string would have to have been
loaded from the configuration rather than received from a hostile
source.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10123 cda61777-01e9-0310-a592-d414129be87e
Don't unconditionally reset scrollback on certain escape sequences.

Handlers for a number of escape sequences, notably including ESC[J and
the sequences that switch to/from the alternate screen, were
unconditionally resetting the scrollback instead of first checking the
'Reset scrollback on display activity' configuration option. I've
added the missing if statements, so now 'Reset scrollback on display
activity' should actually mean what it says.

For example, this would have inconvenienced an mplayer user, who
wouldn't be able to go up and check their scrollback while mplayer was
repeatedly redisplaying its status line, because mplayer uses ESC[J to
erase each version of the status line before printing the next
version.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10125 cda61777-01e9-0310-a592-d414129be87e