sbcsgen.pl uses 'select' to point Perl at a different default output
handle. Revert that when we hackily call it from mkfiles.pl, so that
if I have a need to insert diagnostics in the latter they won't go
into the end of sbcsdat.c.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10013 cda61777-01e9-0310-a592-d414129be87e
It turns out I was a little over-strict in my handling of EOF in
pscp.c when I did the big revamp in r9279: I assumed that in any SCP
connection we would be the first to send EOF, but in fact this isn't
true - doing downloads with old-SCP, EOF is initiated by the server,
so we were spuriously reporting an error for 'unexpected' EOF when
everything had gone fine. Thanks to Nathan Phelan for the report.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10016 cda61777-01e9-0310-a592-d414129be87e
Sebastian Kuschel reports that pfd_closing can be called for a socket
error with pr->c NULL, in which case calling sshfwd_unclean_close on
it will dereference NULL and segfault. Write an alternative error
handling path for that possibility.

(I don't know if it's the only way, but one way this can happen is if
you're doing dynamic forwarding and the socket error occurs during
SOCKS negotiation, in which case no SSH channel has been set up yet
because we haven't yet found out what we want to put in the
direct-tcpip channel open message.)


git-svn-id: svn://svn.tartarus.org/sgt/putty@10018 cda61777-01e9-0310-a592-d414129be87e
Add a general way to request an immediate top-level callback.

This is a little like schedule_timer, in that the callback you provide
will be run from the top-level message loop of whatever application
you're in; but unlike the timer mechanism, it will happen
_immediately_.

The aim is to provide a general way to avoid re-entrance of code, in
cases where just _doing_ the thing you want done is liable to trigger
a confusing recursive call to the function in which you came to the
decision to do it; instead, you just request a top-level callback at
the message loop's earliest convenience, and do it then.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10019 cda61777-01e9-0310-a592-d414129be87e
Revamp the terminal paste mechanism using toplevel callbacks.

I've removed the ad-hoc front-end bodgery in the Windows and GTK ports
to arrange for term_paste to be called at the right moments, and
instead, terminal.c itself deals with knowing when to send the next
chunk of pasted data using a combination of timers and the new
top-level callback mechanism.

As a happy side effect, it's now all in one place so I can actually
understand what it's doing! It turns out that what all that confusing
code was up to is: send a line of pasted data, and delay sending the
next line until either a CR or LF is returned from the server
(typically indicating that the pasted text has been received and
echoed) or 450ms elapse, whichever comes first.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10020 cda61777-01e9-0310-a592-d414129be87e
Revamp Windows's close_session() using toplevel callbacks.

Instead of setting a must_close_session flag and having special code
in the message loop to check it, we'll schedule the call to
close_session using the new top-level callback system.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10021 cda61777-01e9-0310-a592-d414129be87e
Revamp GTK's session close handling using toplevel callbacks.

Instead of having a special GTK idle function for dealing with session
closing, I now use the new top-level callback mechanism which is
slightly simpler for calling a one-off function.

Also in this commit, I've arranged for connection_fatal to queue a
call to the same session close function after displaying the message
box, with the effect that now all the same processing takes place no
matter whether the session closes cleanly or uncleanly - e.g. the SSH
specials submenu is cleaned out, as it should be.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10022 cda61777-01e9-0310-a592-d414129be87e
Revamp net_pending_errors using toplevel callbacks.

Again, I've removed the special-purpose ad-hockery from the assorted
front end message loops that dealt with deferred handling of socket
errors, and instead uxnet.c and winnet.c arrange that for themselves
by calling the new general top-level callback mechanism.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10023 cda61777-01e9-0310-a592-d414129be87e
Revamp Windows pending_netevent using toplevel callbacks.

This greatly simplifies the process of calling select_result() from
the top level after receiving WM_NETEVENT.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10024 cda61777-01e9-0310-a592-d414129be87e
Make calling term_nopaste() a cross-platform feature.

It was one of those things that went in ages ago on Windows and never
got replicated in the Unix front end. And it needn't be: ldisc.c is a
perfect place to put it, since it knows which of the data it's sending
is based on a keystroke and which is automatically generated, and it
also has access to the terminal context. So now a keypress can
interrupt a runaway paste on all platforms.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10025 cda61777-01e9-0310-a592-d414129be87e
Sensibly enforce non-interactive rekeying.

We now only present the full set of host key algorithms we can handle
in the first key exchange. In subsequent rekeys, we present only the
host key algorithm that we agreed on the previous time, and then we
verify the host key by simply enforcing that it's exactly the same as
the one we saw at first and disconnecting rudely if it isn't.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10027 cda61777-01e9-0310-a592-d414129be87e
Don't run toplevel callbacks in modal dialogs.

Because some of them can call gtk_main_quit(), which completely
confuses the dialog box system.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10029 cda61777-01e9-0310-a592-d414129be87e
Fix handling of IPv6 dynamic forwardings.

During the Conf revamp, I changed the internal representation of
dynamic forwardings so that they were stored as the conceptually
sensible L12345=D rather than the old D12345, and added compensation
code to translate to the latter form for backwards-compatible data
storage and for OpenSSH-harmonised GUI display. Unfortunately I forgot
that keys in the forwarding data can also prefix the L/R with a
character indicating IPv4/IPv6, and my translations didn't take
account of that possibility. Fix them.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10031 cda61777-01e9-0310-a592-d414129be87e
Fix free of an uninitialised pointer.

CHAN_AGENT channels need c->u.a.message to be either NULL or valid
dynamically allocated memory, because it'll be freed by
ssh_channel_destroy. This bug triggers if an agent forwarding channel
is opened and closed without having sent any queries.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10032 cda61777-01e9-0310-a592-d414129be87e
Make logparse handle completely bogus channel numbers.

Previously it would throw a bunch of Perl undefined-variable-usage
warnings; now it cleanly detects the problem, dumps as much of the
message as it still reasonably can, and doesn't update any channel
states.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10036 cda61777-01e9-0310-a592-d414129be87e
Fix SSH2_MSG_CHANNEL_EXTENDED_DATA in logparse.

It looks as if it's never worked at all: it had a spurious second
printf, it completely forgot to allow for the uint32 type code that
SSH2_MSG_CHANNEL_DATA doesn't have, it accessed the channel state's
sequence number fields in a way that made no sense and didn't match
the rest of the program, *and* it misinvoked the file opening API. I
must have never had an occasion to test it.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10037 cda61777-01e9-0310-a592-d414129be87e
Pass an error message through to sshfwd_unclean_close.

We have access to one at every call site, so there's really no reason
not to send it through to ssh.c to be logged.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10038 cda61777-01e9-0310-a592-d414129be87e
Handle socket errors on half-open channels.

Anthony Ho reports that this can occur naturally in some situation
involving Windows 8 + IE 11 and dynamic port forwarding: apparently we
get through the SOCKS negotiation, send our CHANNEL_OPEN, and then
*immediately* suffer a local WSAECONNABORTED error before the server
has sent back its OPEN_CONFIRMATION or OPEN_FAILURE. In this situation
ssh2_channel_check_close was failing to notice that the channel didn't
yet have a valid server id, and sending out a CHANNEL_CLOSE anyway
containing 32 bits of uninitialised nonsense.

We now handle this by turning our half-open CHAN_SOCKDATA_DORMANT into
a half-open CHAN_ZOMBIE, which means in turn that our handler
functions for OPEN_CONFIRMATION and OPEN_FAILURE have to recognise and
handle that case, the former by immediately initiating channel closure
once we _do_ have the channel's server id to do it with.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10039 cda61777-01e9-0310-a592-d414129be87e
Only run one toplevel callback per event loop iteration.

This change attempts to reinstate as a universal property something
which was sporadically true of the ad-hockery that came before
toplevel callbacks: that if there's a _very long_ queue of things to
be done through the callback mechanism, the doing of them will be
interleaved with re-checks of other event sources, which might (e.g.)
cause a flag to be set which makes the next callback decide not to do
anything after all.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10040 cda61777-01e9-0310-a592-d414129be87e
Remove the timed part of the terminal paste mechanism.

In r10020 I carefully reimplemented using timing.c and callback.c the
same policy for large pastes that the previous code appeared to be
implementing ad-hoc, which included a 450ms delay between sending
successive lines of pasted text if no visible acknowledgment of the
just-sent line (in the form of a \n or \r) came back from the
application.

However, it turns out that that *wasn't* what the old code was doing.
It *would* have done that, but for the bug that it never actually set
the 'last_paste' variable, and never has done since it was first
introduced way back in r516! So the policy I thought had been in force
forever has in fact only been in force since I unwittingly fixed that
bug in r10020 - and it turns out to be a bad idea, breaking pastes
into vi in particular.

So I've removed the timed paste code completely, on the basis that
it's never actually worked and nobody seems to have been unhappy about
that. Now we still break large pastes into separate lines and send
them in successive top-level callbacks, and the user can still press a
key to interrupt a paste if they manage to catch it still going on,
but there's no attempted *delay* any more.

(It's possible that what I *really* ought to be doing is calling
back->sendbuffer() to see whether the backend is consuming the data
pasted so far, and if not, deferring the rest of the paste until the
send buffer becomes smaller. Then we could have pasting be delayed by
back-pressure from the recipient, and still manually interruptible
during that delay, but not have it delayed by anything else. But what
we have here should at least manage to be equivalent to the *actual*
rather than the intended old policy.)


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