Differences From Artifact [e6b822ef3d]:
- File x11fwd.c — part of check-in [a2c0243430] at 2011-07-14 13:52:21 on branch trunk — Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. (user: simon size: 23386)
To Artifact [277541ede6]:
- File x11fwd.c — part of check-in [0831792ea4] at 2011-09-13 06:44:03 on branch trunk — Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). (user: simon size: 23569)
| ︙ | ︙ | |||
503 504 505 506 507 508 509 510 |
{
struct X11Private *pr = (struct X11Private *) plug;
/*
* We have no way to communicate down the forwarded connection,
* so if an error occurred on the socket, we just ignore it
* and treat it like a proper close.
*/
| > > > > | < | 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 |
{
struct X11Private *pr = (struct X11Private *) plug;
/*
* We have no way to communicate down the forwarded connection,
* so if an error occurred on the socket, we just ignore it
* and treat it like a proper close.
*
* FIXME: except we could initiate a full close here instead of
* just an outgoing EOF? ssh.c currently has no API for that, but
* it could.
*/
sshfwd_write_eof(pr->c);
return 1;
}
static int x11_receive(Plug plug, int urgent, char *data, int len)
{
struct X11Private *pr = (struct X11Private *) plug;
|
| ︙ | ︙ | |||
717 718 719 720 721 722 723 | reply[0] = 0; /* failure */ reply[1] = msglen; /* length of reason string */ memcpy(reply + 2, pr->firstpkt + 2, 4); /* major/minor proto vsn */ PUT_16BIT(pr->firstpkt[0], reply + 6, msgsize >> 2);/* data len */ memset(reply + 8, 0, msgsize); memcpy(reply + 8, message, msglen); sshfwd_write(pr->c, (char *)reply, 8 + msgsize); | | < | 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 | reply[0] = 0; /* failure */ reply[1] = msglen; /* length of reason string */ memcpy(reply + 2, pr->firstpkt + 2, 4); /* major/minor proto vsn */ PUT_16BIT(pr->firstpkt[0], reply + 6, msgsize >> 2);/* data len */ memset(reply + 8, 0, msgsize); memcpy(reply + 8, message, msglen); sshfwd_write(pr->c, (char *)reply, 8 + msgsize); sshfwd_write_eof(pr->c); sfree(reply); sfree(message); return 0; } /* * Now we know we're going to accept the connection. Strip |
| ︙ | ︙ | |||
783 784 785 786 787 788 789 |
/*
* After initialisation, just copy data simply.
*/
return sk_write(s, data, len);
}
| > > > > > | 785 786 787 788 789 790 791 792 793 794 795 796 |
/*
* After initialisation, just copy data simply.
*/
return sk_write(s, data, len);
}
void x11_send_eof(Socket s)
{
sk_write_eof(s);
}
|