2002-10-07 16:45:23 +00:00
|
|
|
#ifndef PUTTY_UNIX_H
|
|
|
|
|
#define PUTTY_UNIX_H
|
|
|
|
|
|
2005-04-25 15:55:06 +00:00
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
|
# include "uxconfig.h" /* Space to hide it from mkfiles.pl */
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
#include <stdio.h> /* for FILENAME_MAX */
|
|
|
|
|
#include <stdint.h> /* C99 int types */
|
2010-05-19 18:22:17 +00:00
|
|
|
#ifndef NO_LIBDL
|
2019-09-08 19:29:00 +00:00
|
|
|
#include <dlfcn.h> /* Dynamic library loading */
|
2010-05-19 18:22:17 +00:00
|
|
|
#endif /* NO_LIBDL */
|
2002-12-31 12:20:34 +00:00
|
|
|
#include "charset.h"
|
2016-08-07 20:02:55 +00:00
|
|
|
#include <sys/types.h> /* for mode_t */
|
2002-12-31 12:20:34 +00:00
|
|
|
|
2015-08-31 12:05:51 +00:00
|
|
|
#ifdef OSX_GTK
|
|
|
|
|
/*
|
|
|
|
|
* Assorted tweaks to various parts of the GTK front end which all
|
|
|
|
|
* need to be enabled when compiling on OS X. Because I might need the
|
|
|
|
|
* same tweaks on other systems in future, I don't want to
|
|
|
|
|
* conditionalise all of them on OSX_GTK directly, so instead, each
|
|
|
|
|
* one has its own name and we enable them all centrally here if
|
|
|
|
|
* OSX_GTK is defined at configure time.
|
|
|
|
|
*/
|
|
|
|
|
#define NOT_X_WINDOWS /* of course, all the X11 stuff should be disabled */
|
|
|
|
|
#define NO_PTY_PRE_INIT /* OS X gets very huffy if we try to set[ug]id */
|
|
|
|
|
#define SET_NONBLOCK_VIA_OPENPT /* work around missing fcntl functionality */
|
2015-09-01 18:00:25 +00:00
|
|
|
#define OSX_META_KEY_CONFIG /* two possible Meta keys to choose from */
|
2015-09-01 18:10:29 +00:00
|
|
|
/* this potential one of the Meta keys needs manual handling */
|
|
|
|
|
#define META_MANUAL_MASK (GDK_MOD1_MASK)
|
2015-09-02 20:37:33 +00:00
|
|
|
#define JUST_USE_GTK_CLIPBOARD_UTF8 /* low-level gdk_selection_* fails */
|
2017-01-21 14:55:53 +00:00
|
|
|
|
2017-02-22 22:10:05 +00:00
|
|
|
#define BUILDINFO_PLATFORM_GTK "OS X (GTK)"
|
2017-02-15 19:29:05 +00:00
|
|
|
#define BUILDINFO_GTK
|
2017-01-21 14:55:53 +00:00
|
|
|
|
|
|
|
|
#elif defined NOT_X_WINDOWS
|
|
|
|
|
|
2017-02-22 22:10:05 +00:00
|
|
|
#define BUILDINFO_PLATFORM_GTK "Unix (pure GTK)"
|
2017-02-15 19:29:05 +00:00
|
|
|
#define BUILDINFO_GTK
|
2017-01-21 14:55:53 +00:00
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
2017-02-22 22:10:05 +00:00
|
|
|
#define BUILDINFO_PLATFORM_GTK "Unix (GTK + X11)"
|
2017-02-15 19:29:05 +00:00
|
|
|
#define BUILDINFO_GTK
|
2017-01-21 14:55:53 +00:00
|
|
|
|
2015-08-31 12:05:51 +00:00
|
|
|
#endif
|
|
|
|
|
|
2017-02-22 22:10:05 +00:00
|
|
|
/* BUILDINFO_PLATFORM varies its expansion between the GTK and
|
|
|
|
|
* pure-CLI utilities, so that Unix Plink, PSFTP etc don't announce
|
|
|
|
|
* themselves incongruously as having something to do with GTK. */
|
|
|
|
|
#define BUILDINFO_PLATFORM_CLI "Unix"
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
extern const bool buildinfo_gtk_relevant;
|
2017-02-22 22:10:05 +00:00
|
|
|
#define BUILDINFO_PLATFORM (buildinfo_gtk_relevant ? \
|
|
|
|
|
BUILDINFO_PLATFORM_GTK : BUILDINFO_PLATFORM_CLI)
|
|
|
|
|
|
2017-02-15 19:29:05 +00:00
|
|
|
char *buildinfo_gtk_version(void);
|
|
|
|
|
|
2003-02-01 12:54:40 +00:00
|
|
|
struct Filename {
|
2011-10-02 11:01:57 +00:00
|
|
|
char *path;
|
2003-02-01 12:54:40 +00:00
|
|
|
};
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
FILE *f_open(const struct Filename *, char const *, bool);
|
2003-02-01 12:54:40 +00:00
|
|
|
|
|
|
|
|
struct FontSpec {
|
2011-10-01 17:38:59 +00:00
|
|
|
char *name; /* may be "" to indicate no selected font at all */
|
2003-02-01 12:54:40 +00:00
|
|
|
};
|
2011-10-01 17:38:59 +00:00
|
|
|
struct FontSpec *fontspec_new(const char *name);
|
2003-02-01 12:54:40 +00:00
|
|
|
|
2018-10-05 06:03:46 +00:00
|
|
|
extern const struct BackendVtable pty_backend;
|
2002-10-09 18:09:42 +00:00
|
|
|
|
2015-09-25 11:05:55 +00:00
|
|
|
#define BROKEN_PIPE_ERROR_CODE EPIPE /* used in sshshare.c */
|
|
|
|
|
|
2002-10-13 11:24:25 +00:00
|
|
|
/*
|
|
|
|
|
* Under GTK, we send MA_CLICK _and_ MA_2CLK, or MA_CLICK _and_
|
|
|
|
|
* MA_3CLK, when a button is pressed for the second or third time.
|
|
|
|
|
*/
|
|
|
|
|
#define MULTICLICK_ONLY_EVENT 0
|
|
|
|
|
|
2003-03-13 19:52:28 +00:00
|
|
|
/*
|
|
|
|
|
* Under GTK, there is no context help available.
|
|
|
|
|
*/
|
|
|
|
|
#define HELPCTX(x) P(NULL)
|
|
|
|
|
#define FILTER_KEY_FILES NULL /* FIXME */
|
2010-09-25 07:16:56 +00:00
|
|
|
#define FILTER_DYNLIB_FILES NULL /* FIXME */
|
2003-03-13 19:52:28 +00:00
|
|
|
|
2002-10-13 11:24:25 +00:00
|
|
|
/*
|
|
|
|
|
* Under X, selection data must not be NUL-terminated.
|
|
|
|
|
*/
|
|
|
|
|
#define SELECTION_NUL_TERMINATED 0
|
|
|
|
|
|
2002-10-14 09:06:31 +00:00
|
|
|
/*
|
|
|
|
|
* Under X, copying to the clipboard terminates lines with just LF.
|
|
|
|
|
*/
|
|
|
|
|
#define SEL_NL { 10 }
|
|
|
|
|
|
2002-10-07 16:45:23 +00:00
|
|
|
/* Simple wraparound timer function */
|
2016-05-17 11:07:36 +00:00
|
|
|
unsigned long getticks(void);
|
2002-10-07 16:45:23 +00:00
|
|
|
#define GETTICKCOUNT getticks
|
2019-09-08 19:29:00 +00:00
|
|
|
#define TICKSPERSEC 1000 /* we choose to use milliseconds */
|
|
|
|
|
#define CURSORBLINK 450 /* no standard way to set this */
|
2002-10-07 16:45:23 +00:00
|
|
|
|
|
|
|
|
#define WCHAR wchar_t
|
|
|
|
|
#define BYTE unsigned char
|
|
|
|
|
|
2017-12-10 10:23:39 +00:00
|
|
|
#define PLATFORM_CLIPBOARDS(X) \
|
|
|
|
|
X(CLIP_PRIMARY, "X11 primary selection") \
|
|
|
|
|
X(CLIP_CLIPBOARD, "XDG clipboard") \
|
2017-12-17 18:44:27 +00:00
|
|
|
X(CLIP_CUSTOM_1, "<custom#1>") \
|
|
|
|
|
X(CLIP_CUSTOM_2, "<custom#2>") \
|
|
|
|
|
X(CLIP_CUSTOM_3, "<custom#3>") \
|
2017-12-09 12:00:13 +00:00
|
|
|
/* end of list */
|
|
|
|
|
|
2017-12-10 10:23:39 +00:00
|
|
|
#ifdef OSX_GTK
|
|
|
|
|
/* OS X has no PRIMARY selection */
|
2017-12-10 17:16:50 +00:00
|
|
|
#define MOUSE_SELECT_CLIPBOARD CLIP_NULL
|
|
|
|
|
#define MOUSE_PASTE_CLIPBOARD CLIP_LOCAL
|
|
|
|
|
#define CLIPNAME_IMPLICIT "Last selected text"
|
|
|
|
|
#define CLIPNAME_EXPLICIT "System clipboard"
|
|
|
|
|
#define CLIPNAME_EXPLICIT_OBJECT "system clipboard"
|
|
|
|
|
/* These defaults are the ones that more or less comply with the OS X
|
|
|
|
|
* Human Interface Guidelines, i.e. copy/paste to the system clipboard
|
|
|
|
|
* is _not_ implicit but requires a specific UI action. This is at
|
|
|
|
|
* odds with all other PuTTY front ends' defaults, but on OS X there
|
|
|
|
|
* is no multi-decade precedent for PuTTY working the other way. */
|
2018-10-29 19:50:29 +00:00
|
|
|
#define CLIPUI_DEFAULT_AUTOCOPY false
|
2017-12-10 17:16:50 +00:00
|
|
|
#define CLIPUI_DEFAULT_MOUSE CLIPUI_IMPLICIT
|
|
|
|
|
#define CLIPUI_DEFAULT_INS CLIPUI_EXPLICIT
|
2017-12-18 10:31:42 +00:00
|
|
|
#define MENU_CLIPBOARD CLIP_CLIPBOARD
|
|
|
|
|
#define COPYALL_CLIPBOARDS CLIP_CLIPBOARD
|
2017-12-10 10:23:39 +00:00
|
|
|
#else
|
|
|
|
|
#define MOUSE_SELECT_CLIPBOARD CLIP_PRIMARY
|
|
|
|
|
#define MOUSE_PASTE_CLIPBOARD CLIP_PRIMARY
|
2017-12-10 17:16:50 +00:00
|
|
|
#define CLIPNAME_IMPLICIT "PRIMARY"
|
|
|
|
|
#define CLIPNAME_EXPLICIT "CLIPBOARD"
|
|
|
|
|
#define CLIPNAME_EXPLICIT_OBJECT "CLIPBOARD"
|
|
|
|
|
/* These defaults are the ones Unix PuTTY has historically had since
|
|
|
|
|
* it was first thought of in 2002 */
|
2018-10-29 19:50:29 +00:00
|
|
|
#define CLIPUI_DEFAULT_AUTOCOPY false
|
2017-12-10 17:16:50 +00:00
|
|
|
#define CLIPUI_DEFAULT_MOUSE CLIPUI_IMPLICIT
|
|
|
|
|
#define CLIPUI_DEFAULT_INS CLIPUI_IMPLICIT
|
2017-12-17 20:35:45 +00:00
|
|
|
#define MENU_CLIPBOARD CLIP_CLIPBOARD
|
|
|
|
|
#define COPYALL_CLIPBOARDS CLIP_PRIMARY, CLIP_CLIPBOARD
|
2017-12-17 18:44:27 +00:00
|
|
|
/* X11 supports arbitrary named clipboards */
|
|
|
|
|
#define NAMED_CLIPBOARDS
|
2017-12-10 10:23:39 +00:00
|
|
|
#endif
|
|
|
|
|
|
Divide the whole of gtkwin.c into three parts.
This lays further groundwork for the OS X GTK3 port, which is going to
have to deal with multiple sessions sharing the same process. gtkwin.c
was a bit too monolithic for this, since it included some
process-global runtime state (timers, toplevel callbacks), some
process startup stuff (gtk_init, gtk_main, argv processing) and some
per-session-window stuff.
The per-session stuff remains in gtkwin.c, with the top-level function
now being new_session_window() taking a Conf. The new gtkmain.c
contains the outer skeleton of pt_main(), handling argv processing and
one-off startup stuff like setlocale; and the new gtkcomm.c contains
the pieces of PuTTY infrastructure like timers and uxsel that are
shared between multiple sessions rather than reinstantiated per
session, which have been rewritten to use global variables rather than
fields in 'inst' (since it's now clear to me that they'll have to
apply to all the insts in existence at once).
There are still some lurking assumptions of one-session-per-process,
e.g. the use of gtk_main_quit when a session finishes, and the fact
that the config box insists on running as a separate invocation of
gtk_main so that one session's preliminary config box can't coexist
with another session already active. But this should make it possible
to at least write an OS X app good enough to start testing with, even
if it doesn't get everything quite right yet.
This change is almost entirely rearranging existing code, so it
shouldn't be seriously destabilising. But two noticeable actual
changes have happened, both pleasantly simplifying:
Firstly, the global-variables rewrite of gtkcomm.c has allowed the
post_main edifice to become a great deal simpler. Most of its
complexity was about remembering what 'inst' it had to call back to,
and in fact the right answer is that it shouldn't be calling back to
one at all. So now the post_main() called by gtkdlg.c has become the
same function as the old inst_post_main() that actually did the work,
instead of the two having to be connected by a piece of ugly plumbing.
Secondly, a piece of code that's vanished completely in this
refactoring is the temporary blocking of SIGCHLD around most of the
session setup code. This turns out to have been introduced in 2002,
_before_ I switched to using the intra-process signal pipe strategy
for SIGCHLD handling in 2003. So I now expect that we should be robust
in any case against receiving SIGCHLD at an inconvenient moment, and
hence there's no need to block it.
2016-03-22 21:24:30 +00:00
|
|
|
/* The per-session frontend structure managed by gtkwin.c */
|
Remove the 'Frontend' type and replace it with a vtable.
After the recent Seat and LogContext revamps, _nearly_ all the
remaining uses of the type 'Frontend' were in terminal.c, which needs
all sorts of interactions with the GUI window the terminal lives in,
from the obvious (actually drawing text on the window, reading and
writing the clipboard) to the obscure (minimising, maximising and
moving the window in response to particular escape sequences).
All of those functions are now provided by an abstraction called
TermWin. The few remaining uses of Frontend after _that_ are internal
to a particular platform directory, so as to spread the implementation
of that particular kind of Frontend between multiple source files; so
I've renamed all of those so that they take a more specifically named
type that refers to the particular implementation rather than the
general abstraction.
So now the name 'Frontend' no longer exists in the code base at all,
and everywhere one used to be used, it's completely clear whether it
was operating in one of Frontend's three abstract roles (and if so,
which), or whether it was specific to a particular implementation.
Another type that's disappeared is 'Context', which used to be a
typedef defined to something different on each platform, describing
whatever short-lived resources were necessary to draw on the terminal
window: the front end would provide a ready-made one when calling
term_paint, and the terminal could request one with get_ctx/free_ctx
if it wanted to do proactive window updates. Now that drawing context
lives inside the TermWin itself, because there was never any need to
have two of those contexts live at the same time.
(Another minor API change is that the window-title functions - both
reading and writing - have had a missing 'const' added to their char *
parameters / return values.)
I don't expect this change to enable any particularly interesting new
functionality (in particular, I have no plans that need more than one
implementation of TermWin in the same application). But it completes
the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
|
|
|
typedef struct GtkFrontend GtkFrontend;
|
Make the configuration dialog non-modal.
Now every call to do_config_box is replaced with a call to
create_config_box, which returns immediately having constructed the
new GTK window object, and is passed a callback function which it will
arrange to be called when the dialog terminates (whether by OK or by
Cancel). That callback is now what triggers the construction of a
session window after 'Open' is pressed in the initial config box, or
the actual mid-session reconfiguration action after 'Apply' is pressed
in a Change Settings box.
We were already prepared to ignore the re-selection of 'Change
Settings' from the context menu of a window that already had a Change
Settings box open (and not accidentally create a second config box for
the same window); but now we do slightly better, by finding the
existing config box and un-minimising and raising it, in case the user
had forgotten it was there.
That's a useful featurelet, but not the main purpose of this change.
The mani point, of course, is that now the multi-window GtkApplication
based front ends now don't do anything confusing to the nesting of
gtk_main() when config boxes are involved. Whether you're changing the
settings of one (or more than one) of your already-running sessions,
preparing to start up a new PuTTY connection, or both at once, we stay
in the same top-level instance of gtk_main() and all sessions' top-
level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
|
|
|
|
2017-11-26 17:07:47 +00:00
|
|
|
/* Callback when a dialog box finishes, and a no-op implementation of it */
|
Make the configuration dialog non-modal.
Now every call to do_config_box is replaced with a call to
create_config_box, which returns immediately having constructed the
new GTK window object, and is passed a callback function which it will
arrange to be called when the dialog terminates (whether by OK or by
Cancel). That callback is now what triggers the construction of a
session window after 'Open' is pressed in the initial config box, or
the actual mid-session reconfiguration action after 'Apply' is pressed
in a Change Settings box.
We were already prepared to ignore the re-selection of 'Change
Settings' from the context menu of a window that already had a Change
Settings box open (and not accidentally create a second config box for
the same window); but now we do slightly better, by finding the
existing config box and un-minimising and raising it, in case the user
had forgotten it was there.
That's a useful featurelet, but not the main purpose of this change.
The mani point, of course, is that now the multi-window GtkApplication
based front ends now don't do anything confusing to the nesting of
gtk_main() when config boxes are involved. Whether you're changing the
settings of one (or more than one) of your already-running sessions,
preparing to start up a new PuTTY connection, or both at once, we stay
in the same top-level instance of gtk_main() and all sessions' top-
level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
|
|
|
typedef void (*post_dialog_fn_t)(void *ctx, int result);
|
2017-11-26 17:07:47 +00:00
|
|
|
void trivial_post_dialog_fn(void *vctx, int result);
|
Make the configuration dialog non-modal.
Now every call to do_config_box is replaced with a call to
create_config_box, which returns immediately having constructed the
new GTK window object, and is passed a callback function which it will
arrange to be called when the dialog terminates (whether by OK or by
Cancel). That callback is now what triggers the construction of a
session window after 'Open' is pressed in the initial config box, or
the actual mid-session reconfiguration action after 'Apply' is pressed
in a Change Settings box.
We were already prepared to ignore the re-selection of 'Change
Settings' from the context menu of a window that already had a Change
Settings box open (and not accidentally create a second config box for
the same window); but now we do slightly better, by finding the
existing config box and un-minimising and raising it, in case the user
had forgotten it was there.
That's a useful featurelet, but not the main purpose of this change.
The mani point, of course, is that now the multi-window GtkApplication
based front ends now don't do anything confusing to the nesting of
gtk_main() when config boxes are involved. Whether you're changing the
settings of one (or more than one) of your already-running sessions,
preparing to start up a new PuTTY connection, or both at once, we stay
in the same top-level instance of gtk_main() and all sessions' top-
level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
|
|
|
|
|
|
|
|
/* Start up a session window, with or without a preliminary config box */
|
|
|
|
|
void initial_config_box(Conf *conf, post_dialog_fn_t after, void *afterctx);
|
|
|
|
|
void new_session_window(Conf *conf, const char *geometry_string);
|
Divide the whole of gtkwin.c into three parts.
This lays further groundwork for the OS X GTK3 port, which is going to
have to deal with multiple sessions sharing the same process. gtkwin.c
was a bit too monolithic for this, since it included some
process-global runtime state (timers, toplevel callbacks), some
process startup stuff (gtk_init, gtk_main, argv processing) and some
per-session-window stuff.
The per-session stuff remains in gtkwin.c, with the top-level function
now being new_session_window() taking a Conf. The new gtkmain.c
contains the outer skeleton of pt_main(), handling argv processing and
one-off startup stuff like setlocale; and the new gtkcomm.c contains
the pieces of PuTTY infrastructure like timers and uxsel that are
shared between multiple sessions rather than reinstantiated per
session, which have been rewritten to use global variables rather than
fields in 'inst' (since it's now clear to me that they'll have to
apply to all the insts in existence at once).
There are still some lurking assumptions of one-session-per-process,
e.g. the use of gtk_main_quit when a session finishes, and the fact
that the config box insists on running as a separate invocation of
gtk_main so that one session's preliminary config box can't coexist
with another session already active. But this should make it possible
to at least write an OS X app good enough to start testing with, even
if it doesn't get everything quite right yet.
This change is almost entirely rearranging existing code, so it
shouldn't be seriously destabilising. But two noticeable actual
changes have happened, both pleasantly simplifying:
Firstly, the global-variables rewrite of gtkcomm.c has allowed the
post_main edifice to become a great deal simpler. Most of its
complexity was about remembering what 'inst' it had to call back to,
and in fact the right answer is that it shouldn't be calling back to
one at all. So now the post_main() called by gtkdlg.c has become the
same function as the old inst_post_main() that actually did the work,
instead of the two having to be connected by a piece of ugly plumbing.
Secondly, a piece of code that's vanished completely in this
refactoring is the temporary blocking of SIGCHLD around most of the
session setup code. This turns out to have been introduced in 2002,
_before_ I switched to using the intra-process signal pipe strategy
for SIGCHLD handling in 2003. So I now expect that we should be robust
in any case against receiving SIGCHLD at an inconvenient moment, and
hence there's no need to block it.
2016-03-22 21:24:30 +00:00
|
|
|
|
|
|
|
|
/* Defined in gtkmain.c */
|
|
|
|
|
void launch_duplicate_session(Conf *conf);
|
|
|
|
|
void launch_new_session(void);
|
|
|
|
|
void launch_saved_session(const char *str);
|
Make the configuration dialog non-modal.
Now every call to do_config_box is replaced with a call to
create_config_box, which returns immediately having constructed the
new GTK window object, and is passed a callback function which it will
arrange to be called when the dialog terminates (whether by OK or by
Cancel). That callback is now what triggers the construction of a
session window after 'Open' is pressed in the initial config box, or
the actual mid-session reconfiguration action after 'Apply' is pressed
in a Change Settings box.
We were already prepared to ignore the re-selection of 'Change
Settings' from the context menu of a window that already had a Change
Settings box open (and not accidentally create a second config box for
the same window); but now we do slightly better, by finding the
existing config box and un-minimising and raising it, in case the user
had forgotten it was there.
That's a useful featurelet, but not the main purpose of this change.
The mani point, of course, is that now the multi-window GtkApplication
based front ends now don't do anything confusing to the nesting of
gtk_main() when config boxes are involved. Whether you're changing the
settings of one (or more than one) of your already-running sessions,
preparing to start up a new PuTTY connection, or both at once, we stay
in the same top-level instance of gtk_main() and all sessions' top-
level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
|
|
|
void session_window_closed(void);
|
2017-11-27 20:09:54 +00:00
|
|
|
void window_setup_error(const char *errmsg);
|
2016-03-23 22:03:46 +00:00
|
|
|
#ifdef MAY_REFER_TO_GTK_IN_HEADERS
|
Remove the 'Frontend' type and replace it with a vtable.
After the recent Seat and LogContext revamps, _nearly_ all the
remaining uses of the type 'Frontend' were in terminal.c, which needs
all sorts of interactions with the GUI window the terminal lives in,
from the obvious (actually drawing text on the window, reading and
writing the clipboard) to the obscure (minimising, maximising and
moving the window in response to particular escape sequences).
All of those functions are now provided by an abstraction called
TermWin. The few remaining uses of Frontend after _that_ are internal
to a particular platform directory, so as to spread the implementation
of that particular kind of Frontend between multiple source files; so
I've renamed all of those so that they take a more specifically named
type that refers to the particular implementation rather than the
general abstraction.
So now the name 'Frontend' no longer exists in the code base at all,
and everywhere one used to be used, it's completely clear whether it
was operating in one of Frontend's three abstract roles (and if so,
which), or whether it was specific to a particular implementation.
Another type that's disappeared is 'Context', which used to be a
typedef defined to something different on each platform, describing
whatever short-lived resources were necessary to draw on the terminal
window: the front end would provide a ready-made one when calling
term_paint, and the terminal could request one with get_ctx/free_ctx
if it wanted to do proactive window updates. Now that drawing context
lives inside the TermWin itself, because there was never any need to
have two of those contexts live at the same time.
(Another minor API change is that the window-title functions - both
reading and writing - have had a missing 'const' added to their char *
parameters / return values.)
I don't expect this change to enable any particularly interesting new
functionality (in particular, I have no plans that need more than one
implementation of TermWin in the same application). But it completes
the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
|
|
|
GtkWidget *make_gtk_toplevel_window(GtkFrontend *frontend);
|
2016-03-23 22:03:46 +00:00
|
|
|
#endif
|
Divide the whole of gtkwin.c into three parts.
This lays further groundwork for the OS X GTK3 port, which is going to
have to deal with multiple sessions sharing the same process. gtkwin.c
was a bit too monolithic for this, since it included some
process-global runtime state (timers, toplevel callbacks), some
process startup stuff (gtk_init, gtk_main, argv processing) and some
per-session-window stuff.
The per-session stuff remains in gtkwin.c, with the top-level function
now being new_session_window() taking a Conf. The new gtkmain.c
contains the outer skeleton of pt_main(), handling argv processing and
one-off startup stuff like setlocale; and the new gtkcomm.c contains
the pieces of PuTTY infrastructure like timers and uxsel that are
shared between multiple sessions rather than reinstantiated per
session, which have been rewritten to use global variables rather than
fields in 'inst' (since it's now clear to me that they'll have to
apply to all the insts in existence at once).
There are still some lurking assumptions of one-session-per-process,
e.g. the use of gtk_main_quit when a session finishes, and the fact
that the config box insists on running as a separate invocation of
gtk_main so that one session's preliminary config box can't coexist
with another session already active. But this should make it possible
to at least write an OS X app good enough to start testing with, even
if it doesn't get everything quite right yet.
This change is almost entirely rearranging existing code, so it
shouldn't be seriously destabilising. But two noticeable actual
changes have happened, both pleasantly simplifying:
Firstly, the global-variables rewrite of gtkcomm.c has allowed the
post_main edifice to become a great deal simpler. Most of its
complexity was about remembering what 'inst' it had to call back to,
and in fact the right answer is that it shouldn't be calling back to
one at all. So now the post_main() called by gtkdlg.c has become the
same function as the old inst_post_main() that actually did the work,
instead of the two having to be connected by a piece of ugly plumbing.
Secondly, a piece of code that's vanished completely in this
refactoring is the temporary blocking of SIGCHLD around most of the
session setup code. This turns out to have been introduced in 2002,
_before_ I switched to using the intra-process signal pipe strategy
for SIGCHLD handling in 2003. So I now expect that we should be robust
in any case against receiving SIGCHLD at an inconvenient moment, and
hence there's no need to block it.
2016-03-22 21:24:30 +00:00
|
|
|
|
2018-10-05 06:03:46 +00:00
|
|
|
const struct BackendVtable *select_backend(Conf *conf);
|
2018-09-11 15:23:38 +00:00
|
|
|
|
Divide the whole of gtkwin.c into three parts.
This lays further groundwork for the OS X GTK3 port, which is going to
have to deal with multiple sessions sharing the same process. gtkwin.c
was a bit too monolithic for this, since it included some
process-global runtime state (timers, toplevel callbacks), some
process startup stuff (gtk_init, gtk_main, argv processing) and some
per-session-window stuff.
The per-session stuff remains in gtkwin.c, with the top-level function
now being new_session_window() taking a Conf. The new gtkmain.c
contains the outer skeleton of pt_main(), handling argv processing and
one-off startup stuff like setlocale; and the new gtkcomm.c contains
the pieces of PuTTY infrastructure like timers and uxsel that are
shared between multiple sessions rather than reinstantiated per
session, which have been rewritten to use global variables rather than
fields in 'inst' (since it's now clear to me that they'll have to
apply to all the insts in existence at once).
There are still some lurking assumptions of one-session-per-process,
e.g. the use of gtk_main_quit when a session finishes, and the fact
that the config box insists on running as a separate invocation of
gtk_main so that one session's preliminary config box can't coexist
with another session already active. But this should make it possible
to at least write an OS X app good enough to start testing with, even
if it doesn't get everything quite right yet.
This change is almost entirely rearranging existing code, so it
shouldn't be seriously destabilising. But two noticeable actual
changes have happened, both pleasantly simplifying:
Firstly, the global-variables rewrite of gtkcomm.c has allowed the
post_main edifice to become a great deal simpler. Most of its
complexity was about remembering what 'inst' it had to call back to,
and in fact the right answer is that it shouldn't be calling back to
one at all. So now the post_main() called by gtkdlg.c has become the
same function as the old inst_post_main() that actually did the work,
instead of the two having to be connected by a piece of ugly plumbing.
Secondly, a piece of code that's vanished completely in this
refactoring is the temporary blocking of SIGCHLD around most of the
session setup code. This turns out to have been introduced in 2002,
_before_ I switched to using the intra-process signal pipe strategy
for SIGCHLD handling in 2003. So I now expect that we should be robust
in any case against receiving SIGCHLD at an inconvenient moment, and
hence there's no need to block it.
2016-03-22 21:24:30 +00:00
|
|
|
/* Defined in gtkcomm.c */
|
|
|
|
|
void gtkcomm_setup(void);
|
|
|
|
|
|
2017-12-18 11:15:44 +00:00
|
|
|
/* Used to pass application-menu operations from gtkapp.c to gtkwin.c */
|
|
|
|
|
enum MenuAction {
|
2017-12-18 11:46:48 +00:00
|
|
|
MA_COPY, MA_PASTE, MA_COPY_ALL, MA_DUPLICATE_SESSION,
|
|
|
|
|
MA_RESTART_SESSION, MA_CHANGE_SETTINGS, MA_CLEAR_SCROLLBACK,
|
|
|
|
|
MA_RESET_TERMINAL, MA_EVENT_LOG
|
2017-12-18 11:15:44 +00:00
|
|
|
};
|
Remove the 'Frontend' type and replace it with a vtable.
After the recent Seat and LogContext revamps, _nearly_ all the
remaining uses of the type 'Frontend' were in terminal.c, which needs
all sorts of interactions with the GUI window the terminal lives in,
from the obvious (actually drawing text on the window, reading and
writing the clipboard) to the obscure (minimising, maximising and
moving the window in response to particular escape sequences).
All of those functions are now provided by an abstraction called
TermWin. The few remaining uses of Frontend after _that_ are internal
to a particular platform directory, so as to spread the implementation
of that particular kind of Frontend between multiple source files; so
I've renamed all of those so that they take a more specifically named
type that refers to the particular implementation rather than the
general abstraction.
So now the name 'Frontend' no longer exists in the code base at all,
and everywhere one used to be used, it's completely clear whether it
was operating in one of Frontend's three abstract roles (and if so,
which), or whether it was specific to a particular implementation.
Another type that's disappeared is 'Context', which used to be a
typedef defined to something different on each platform, describing
whatever short-lived resources were necessary to draw on the terminal
window: the front end would provide a ready-made one when calling
term_paint, and the terminal could request one with get_ctx/free_ctx
if it wanted to do proactive window updates. Now that drawing context
lives inside the TermWin itself, because there was never any need to
have two of those contexts live at the same time.
(Another minor API change is that the window-title functions - both
reading and writing - have had a missing 'const' added to their char *
parameters / return values.)
I don't expect this change to enable any particularly interesting new
functionality (in particular, I have no plans that need more than one
implementation of TermWin in the same application). But it completes
the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
|
|
|
void app_menu_action(GtkFrontend *frontend, enum MenuAction);
|
2017-12-09 12:00:13 +00:00
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/* Arrays of pixmap data used for GTK window icons. (main_icon is for
|
|
|
|
|
* the process's main window; cfg_icon is the modified icon used for
|
|
|
|
|
* its config box.) */
|
|
|
|
|
extern const char *const *const main_icon[];
|
|
|
|
|
extern const char *const *const cfg_icon[];
|
|
|
|
|
extern const int n_main_icon, n_cfg_icon;
|
|
|
|
|
|
|
|
|
|
/* Things gtkdlg.c needs from gtkwin.c */
|
2017-11-26 14:55:15 +00:00
|
|
|
#ifdef MAY_REFER_TO_GTK_IN_HEADERS
|
2017-11-26 16:51:19 +00:00
|
|
|
enum DialogSlot {
|
|
|
|
|
DIALOG_SLOT_RECONFIGURE,
|
|
|
|
|
DIALOG_SLOT_NETWORK_PROMPT,
|
2017-11-26 16:56:03 +00:00
|
|
|
DIALOG_SLOT_LOGFILE_PROMPT,
|
2017-11-26 17:21:32 +00:00
|
|
|
DIALOG_SLOT_WARN_ON_CLOSE,
|
2017-11-26 19:59:24 +00:00
|
|
|
DIALOG_SLOT_CONNECTION_FATAL,
|
2017-11-26 16:51:19 +00:00
|
|
|
DIALOG_SLOT_LIMIT /* must remain last */
|
|
|
|
|
};
|
New abstraction 'Seat', to pass to backends.
This is a new vtable-based abstraction which is passed to a backend in
place of Frontend, and it implements only the subset of the Frontend
functions needed by a backend. (Many other Frontend functions still
exist, notably the wide range of things called by terminal.c providing
platform-independent operations on the GUI terminal window.)
The purpose of making it a vtable is that this opens up the
possibility of creating a backend as an internal implementation detail
of some other activity, by providing just that one backend with a
custom Seat that implements the methods differently.
For example, this refactoring should make it feasible to directly
implement an SSH proxy type, aka the 'jump host' feature supported by
OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP
mode, and then expose the main channel of that as the Socket for the
primary connection'. (Which of course you can already do by spawning
'plink -nc' as a separate proxy process, but this would permit it in
the _same_ process without anything getting confused.)
I've centralised a full set of stub methods in misc.c for the new
abstraction, which allows me to get rid of several annoying stubs in
the previous code. Also, while I'm here, I've moved a lot of
duplicated modalfatalbox() type functions from application main
program files into wincons.c / uxcons.c, which I think saves
duplication overall. (A minor visible effect is that the prefixes on
those console-based fatal error messages will now be more consistent
between applications.)
2018-10-11 18:58:42 +00:00
|
|
|
GtkWidget *gtk_seat_get_window(Seat *seat);
|
|
|
|
|
void register_dialog(Seat *seat, enum DialogSlot slot, GtkWidget *dialog);
|
|
|
|
|
void unregister_dialog(Seat *seat, enum DialogSlot slot);
|
2018-11-03 10:06:33 +00:00
|
|
|
void set_window_icon(GtkWidget *window, const char *const *const *icon,
|
|
|
|
|
int n_icon);
|
|
|
|
|
extern GdkAtom compound_text_atom;
|
2017-11-26 14:55:15 +00:00
|
|
|
#endif
|
2003-03-31 11:21:07 +00:00
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/* Things gtkwin.c needs from gtkdlg.c */
|
Make the configuration dialog non-modal.
Now every call to do_config_box is replaced with a call to
create_config_box, which returns immediately having constructed the
new GTK window object, and is passed a callback function which it will
arrange to be called when the dialog terminates (whether by OK or by
Cancel). That callback is now what triggers the construction of a
session window after 'Open' is pressed in the initial config box, or
the actual mid-session reconfiguration action after 'Apply' is pressed
in a Change Settings box.
We were already prepared to ignore the re-selection of 'Change
Settings' from the context menu of a window that already had a Change
Settings box open (and not accidentally create a second config box for
the same window); but now we do slightly better, by finding the
existing config box and un-minimising and raising it, in case the user
had forgotten it was there.
That's a useful featurelet, but not the main purpose of this change.
The mani point, of course, is that now the multi-window GtkApplication
based front ends now don't do anything confusing to the nesting of
gtk_main() when config boxes are involved. Whether you're changing the
settings of one (or more than one) of your already-running sessions,
preparing to start up a new PuTTY connection, or both at once, we stay
in the same top-level instance of gtk_main() and all sessions' top-
level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
|
|
|
#ifdef MAY_REFER_TO_GTK_IN_HEADERS
|
|
|
|
|
GtkWidget *create_config_box(const char *title, Conf *conf,
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool midsession, int protcfginfo,
|
Make the configuration dialog non-modal.
Now every call to do_config_box is replaced with a call to
create_config_box, which returns immediately having constructed the
new GTK window object, and is passed a callback function which it will
arrange to be called when the dialog terminates (whether by OK or by
Cancel). That callback is now what triggers the construction of a
session window after 'Open' is pressed in the initial config box, or
the actual mid-session reconfiguration action after 'Apply' is pressed
in a Change Settings box.
We were already prepared to ignore the re-selection of 'Change
Settings' from the context menu of a window that already had a Change
Settings box open (and not accidentally create a second config box for
the same window); but now we do slightly better, by finding the
existing config box and un-minimising and raising it, in case the user
had forgotten it was there.
That's a useful featurelet, but not the main purpose of this change.
The mani point, of course, is that now the multi-window GtkApplication
based front ends now don't do anything confusing to the nesting of
gtk_main() when config boxes are involved. Whether you're changing the
settings of one (or more than one) of your already-running sessions,
preparing to start up a new PuTTY connection, or both at once, we stay
in the same top-level instance of gtk_main() and all sessions' top-
level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
|
|
|
post_dialog_fn_t after, void *afterctx);
|
|
|
|
|
#endif
|
2015-05-15 10:15:42 +00:00
|
|
|
void nonfatal_message_box(void *window, const char *msg);
|
2003-04-10 08:53:43 +00:00
|
|
|
void about_box(void *window);
|
2018-10-08 18:30:01 +00:00
|
|
|
typedef struct eventlog_stuff eventlog_stuff;
|
|
|
|
|
eventlog_stuff *eventlogstuff_new(void);
|
|
|
|
|
void eventlogstuff_free(eventlog_stuff *);
|
|
|
|
|
void showeventlog(eventlog_stuff *estuff, void *parentwin);
|
|
|
|
|
void logevent_dlg(eventlog_stuff *estuff, const char *string);
|
New abstraction 'Seat', to pass to backends.
This is a new vtable-based abstraction which is passed to a backend in
place of Frontend, and it implements only the subset of the Frontend
functions needed by a backend. (Many other Frontend functions still
exist, notably the wide range of things called by terminal.c providing
platform-independent operations on the GUI terminal window.)
The purpose of making it a vtable is that this opens up the
possibility of creating a backend as an internal implementation detail
of some other activity, by providing just that one backend with a
custom Seat that implements the methods differently.
For example, this refactoring should make it feasible to directly
implement an SSH proxy type, aka the 'jump host' feature supported by
OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP
mode, and then expose the main channel of that as the Socket for the
primary connection'. (Which of course you can already do by spawning
'plink -nc' as a separate proxy process, but this would permit it in
the _same_ process without anything getting confused.)
I've centralised a full set of stub methods in misc.c for the new
abstraction, which allows me to get rid of several annoying stubs in
the previous code. Also, while I'm here, I've moved a lot of
duplicated modalfatalbox() type functions from application main
program files into wincons.c / uxcons.c, which I think saves
duplication overall. (A minor visible effect is that the prefixes on
those console-based fatal error messages will now be more consistent
between applications.)
2018-10-11 18:58:42 +00:00
|
|
|
int gtkdlg_askappend(Seat *seat, Filename *filename,
|
|
|
|
|
void (*callback)(void *ctx, int result), void *ctx);
|
|
|
|
|
int gtk_seat_verify_ssh_host_key(
|
|
|
|
|
Seat *seat, const char *host, int port,
|
|
|
|
|
const char *keytype, char *keystr, char *fingerprint,
|
|
|
|
|
void (*callback)(void *ctx, int result), void *ctx);
|
|
|
|
|
int gtk_seat_confirm_weak_crypto_primitive(
|
|
|
|
|
Seat *seat, const char *algtype, const char *algname,
|
|
|
|
|
void (*callback)(void *ctx, int result), void *ctx);
|
|
|
|
|
int gtk_seat_confirm_weak_cached_hostkey(
|
|
|
|
|
Seat *seat, const char *algname, const char *betteralgs,
|
|
|
|
|
void (*callback)(void *ctx, int result), void *ctx);
|
2013-01-13 21:59:10 +00:00
|
|
|
#ifdef MAY_REFER_TO_GTK_IN_HEADERS
|
2017-11-26 14:05:02 +00:00
|
|
|
struct message_box_button {
|
|
|
|
|
const char *title;
|
|
|
|
|
char shortcut;
|
|
|
|
|
int type; /* more negative means more appropriate to be the Esc action */
|
|
|
|
|
int value; /* message box's return value if this is pressed */
|
|
|
|
|
};
|
|
|
|
|
struct message_box_buttons {
|
|
|
|
|
const struct message_box_button *buttons;
|
|
|
|
|
int nbuttons;
|
|
|
|
|
};
|
|
|
|
|
extern const struct message_box_buttons buttons_yn, buttons_ok;
|
2017-11-26 17:05:51 +00:00
|
|
|
GtkWidget *create_message_box(
|
|
|
|
|
GtkWidget *parentwin, const char *title, const char *msg, int minwid,
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool selectable, const struct message_box_buttons *buttons,
|
2017-11-26 17:05:51 +00:00
|
|
|
post_dialog_fn_t after, void *afterctx);
|
2013-01-13 21:59:10 +00:00
|
|
|
#endif
|
2003-04-01 18:10:25 +00:00
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/* gtkwin.c needs this special function in xkeysym.c */
|
2003-04-27 11:10:48 +00:00
|
|
|
int keysym_to_unicode(int keysym);
|
|
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/* Things uxstore.c needs from gtkwin.c */
|
2003-01-14 18:43:45 +00:00
|
|
|
char *x_get_default(const char *key);
|
2002-10-16 14:32:06 +00:00
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/* Things uxstore.c provides to gtkwin.c */
|
2019-04-13 18:12:53 +00:00
|
|
|
void provide_xrm_string(const char *string, const char *progname);
|
2002-10-16 22:54:58 +00:00
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/* Function that {gtkapp,gtkmain}.c needs from ux{pterm,putty}.c. Does
|
|
|
|
|
* early process setup that varies between applications (e.g.
|
|
|
|
|
* pty_pre_init or sk_init), and is passed a boolean by the caller
|
|
|
|
|
* indicating whether this is an OS X style multi-session monolithic
|
|
|
|
|
* process or an ordinary Unix one-shot. */
|
|
|
|
|
void setup(bool single_session_in_this_process);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Per-application constants that affect behaviour of shared modules.
|
|
|
|
|
*/
|
|
|
|
|
/* Do we need an Event Log menu item? (yes for PuTTY, no for pterm) */
|
|
|
|
|
extern const bool use_event_log;
|
|
|
|
|
/* Do we need a New Session menu item? (yes for PuTTY, no for pterm) */
|
|
|
|
|
extern const bool new_session;
|
|
|
|
|
/* Do we need a Saved Sessions menu item? (yes for PuTTY, no for pterm) */
|
|
|
|
|
extern const bool saved_sessions;
|
|
|
|
|
/* When we Duplicate Session, do we need to double-check that the Conf
|
|
|
|
|
* is in a launchable state? (no for pterm, because conf_launchable
|
|
|
|
|
* returns an irrelevant answer, since we'll force use of the pty
|
|
|
|
|
* backend which ignores all the relevant settings) */
|
|
|
|
|
extern const bool dup_check_launchable;
|
|
|
|
|
/* In the Duplicate Session serialised data, do we send/receive an
|
|
|
|
|
* argv array after the main Conf? (yes for pterm, no for PuTTY) */
|
|
|
|
|
extern const bool use_pty_argv;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* OS X environment munging: this is the prefix we expect to find on
|
|
|
|
|
* environment variable names that were changed by osxlaunch.
|
|
|
|
|
* Extracted from the command line of the OS X pterm main binary, and
|
|
|
|
|
* used in uxpty.c to restore the original environment before
|
|
|
|
|
* launching its subprocess.
|
|
|
|
|
*/
|
|
|
|
|
extern char *pty_osx_envrestore_prefix;
|
|
|
|
|
|
2007-09-29 12:27:45 +00:00
|
|
|
/* Things provided by uxcons.c */
|
|
|
|
|
struct termios;
|
2020-01-30 06:40:21 +00:00
|
|
|
void stderr_tty_init(void); /* call at startup if stderr might be a tty */
|
2007-09-29 12:27:45 +00:00
|
|
|
void premsg(struct termios *);
|
|
|
|
|
void postmsg(struct termios *);
|
|
|
|
|
|
2003-03-29 16:47:06 +00:00
|
|
|
/* The interface used by uxsel.c */
|
2015-08-16 11:50:46 +00:00
|
|
|
typedef struct uxsel_id uxsel_id;
|
2003-03-29 16:47:06 +00:00
|
|
|
void uxsel_init(void);
|
2016-05-30 21:52:30 +00:00
|
|
|
typedef void (*uxsel_callback_fn)(int fd, int event);
|
2003-03-29 16:47:06 +00:00
|
|
|
void uxsel_set(int fd, int rwx, uxsel_callback_fn callback);
|
|
|
|
|
void uxsel_del(int fd);
|
2019-02-07 18:13:56 +00:00
|
|
|
enum { SELECT_R = 1, SELECT_W = 2, SELECT_X = 4 };
|
2016-05-30 21:37:32 +00:00
|
|
|
void select_result(int fd, int event);
|
2003-03-29 16:47:06 +00:00
|
|
|
int first_fd(int *state, int *rwx);
|
|
|
|
|
int next_fd(int *state, int *rwx);
|
2003-03-29 18:30:14 +00:00
|
|
|
/* The following are expected to be provided _to_ uxsel.c by the frontend */
|
2015-08-16 11:50:46 +00:00
|
|
|
uxsel_id *uxsel_input_add(int fd, int rwx); /* returns an id */
|
|
|
|
|
void uxsel_input_remove(uxsel_id *id);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2003-03-14 18:35:01 +00:00
|
|
|
/* uxcfg.c */
|
|
|
|
|
struct controlbox;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
void unix_setup_config_box(
|
|
|
|
|
struct controlbox *b, bool midsession, int protocol);
|
2003-03-14 18:35:01 +00:00
|
|
|
|
2005-02-14 07:41:41 +00:00
|
|
|
/* gtkcfg.c */
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
void gtk_setup_config_box(
|
|
|
|
|
struct controlbox *b, bool midsession, void *window);
|
2005-02-14 07:41:41 +00:00
|
|
|
|
2002-12-31 12:20:34 +00:00
|
|
|
/*
|
|
|
|
|
* In the Unix Unicode layer, DEFAULT_CODEPAGE is a special value
|
|
|
|
|
* which causes mb_to_wc and wc_to_mb to call _libc_ rather than
|
|
|
|
|
* libcharset. That way, we can interface the various charsets
|
|
|
|
|
* supported by libcharset with the one supported by mbstowcs and
|
|
|
|
|
* wcstombs (which will be the character set in which stuff read
|
|
|
|
|
* from the command line or config files is assumed to be encoded).
|
|
|
|
|
*/
|
|
|
|
|
#define DEFAULT_CODEPAGE 0xFFFF
|
2019-09-08 19:29:00 +00:00
|
|
|
#define CP_UTF8 CS_UTF8 /* from libcharset */
|
2002-10-07 16:45:23 +00:00
|
|
|
|
2002-10-30 17:57:31 +00:00
|
|
|
#define strnicmp strncasecmp
|
|
|
|
|
#define stricmp strcasecmp
|
|
|
|
|
|
2004-12-17 14:25:53 +00:00
|
|
|
/* BSD-semantics version of signal(), and another helpful function */
|
2002-11-02 14:35:57 +00:00
|
|
|
void (*putty_signal(int sig, void (*func)(int)))(int);
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
void block_signal(int sig, bool block_it);
|
2002-11-02 14:35:57 +00:00
|
|
|
|
2006-12-09 15:44:31 +00:00
|
|
|
/* uxmisc.c */
|
2013-07-19 18:10:02 +00:00
|
|
|
void cloexec(int);
|
|
|
|
|
void noncloexec(int);
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool nonblock(int);
|
|
|
|
|
bool no_nonblock(int);
|
2015-05-05 19:16:22 +00:00
|
|
|
char *make_dir_and_check_ours(const char *dirname);
|
2016-08-07 20:02:55 +00:00
|
|
|
char *make_dir_path(const char *path, mode_t mode);
|
2006-12-09 15:44:31 +00:00
|
|
|
|
2003-01-01 22:25:25 +00:00
|
|
|
/*
|
|
|
|
|
* Exports from unicode.c.
|
|
|
|
|
*/
|
2003-01-14 18:28:23 +00:00
|
|
|
struct unicode_data;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool init_ucs(struct unicode_data *ucsdata, char *line_codepage,
|
|
|
|
|
bool utf8_override, int font_charset, int vtmode);
|
2003-01-01 22:25:25 +00:00
|
|
|
|
2003-01-11 09:31:54 +00:00
|
|
|
/*
|
2018-10-14 17:48:02 +00:00
|
|
|
* Spare functions exported directly from uxnet.c.
|
2003-01-11 09:31:54 +00:00
|
|
|
*/
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
void *sk_getxdmdata(Socket *sock, int *lenp);
|
Add a /proc/net magic authenticator.
This is a Linux-specific trick that I'm quite fond of: I've used it
before in 'agedu' and a lot of my unpublished personal scriptery.
Suppose you want to run a listening network server in such a way that
it can only accept connections from processes under your own control.
Often it's not convenient to do this by adding an authentication step
to the protocol itself (either because the password management gets
hairy or because the protocol is already well defined). The 'right'
answer is to switch from TCP to Unix-domain sockets, because then you
can use the file permissions on the path leading to the socket inode
to ensure that no other user id can connect to it - but that's often
inconvenient as well, because if any _client_ of the server is not
already prepared to speak AF_UNIX your control then you can only trick
it into connecting to an AF_UNIX socket instead of TCP by applying a
downstream patch or resorting to LD_PRELOAD shenanigans.
But on Linux, there's an alternative shenanigan available, in the form
of /proc/net/tcp (or tcp6), which lists every currently active TCP
endpoint known to the kernel, and for each one, lists an owning uid.
Listen on localhost only. Then, when a connection comes in, look up
the far end of it in that file and see if the owning uid is the right
one!
I've always vaguely wondered if there would be uses for this trick in
PuTTY. One potentially useful one might be to protect the listening
sockets created by local-to-remote port forwarding. But for the
moment, I'm only planning to use it for a less security-critical
purpose, which will appear in the next commit.
2019-03-31 08:24:17 +00:00
|
|
|
int sk_net_get_fd(Socket *sock);
|
2018-10-14 17:48:02 +00:00
|
|
|
SockAddr *unix_sock_addr(const char *path);
|
|
|
|
|
Socket *new_unix_listener(SockAddr *listenaddr, Plug *plug);
|
2003-01-11 09:31:54 +00:00
|
|
|
|
2003-08-24 13:22:17 +00:00
|
|
|
/*
|
|
|
|
|
* General helpful Unix stuff: more helpful version of the FD_SET
|
|
|
|
|
* macro, which also handles maxfd.
|
|
|
|
|
*/
|
|
|
|
|
#define FD_SET_MAX(fd, max, set) do { \
|
|
|
|
|
FD_SET(fd, &set); \
|
|
|
|
|
if (max < fd + 1) max = fd + 1; \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
2006-08-28 14:29:02 +00:00
|
|
|
/*
|
2018-09-11 15:23:38 +00:00
|
|
|
* Exports from uxser.c.
|
2006-08-28 14:29:02 +00:00
|
|
|
*/
|
2018-10-05 06:03:46 +00:00
|
|
|
extern const struct BackendVtable serial_backend;
|
2006-08-28 14:29:02 +00:00
|
|
|
|
2015-05-18 12:57:45 +00:00
|
|
|
/*
|
|
|
|
|
* uxpeer.c, wrapping getsockopt(SO_PEERCRED).
|
|
|
|
|
*/
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool so_peercred(int fd, int *pid, int *uid, int *gid);
|
2015-05-18 12:57:45 +00:00
|
|
|
|
2018-10-07 13:55:32 +00:00
|
|
|
/*
|
|
|
|
|
* uxfdsock.c.
|
|
|
|
|
*/
|
|
|
|
|
Socket *make_fd_socket(int infd, int outfd, int inerrfd, Plug *plug);
|
|
|
|
|
|
2015-08-31 12:24:09 +00:00
|
|
|
/*
|
|
|
|
|
* Default font setting, which can vary depending on NOT_X_WINDOWS.
|
|
|
|
|
*/
|
|
|
|
|
#ifdef NOT_X_WINDOWS
|
|
|
|
|
#define DEFAULT_GTK_FONT "client:Monospace 12"
|
|
|
|
|
#else
|
|
|
|
|
#define DEFAULT_GTK_FONT "server:fixed"
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/*
|
|
|
|
|
* uxpty.c.
|
|
|
|
|
*/
|
|
|
|
|
void pty_pre_init(void); /* pty+utmp setup before dropping privilege */
|
|
|
|
|
/* Pass in the argv[] for an instance of the pty backend created by
|
|
|
|
|
* the standard vtable constructor. Only called from (non-OSX) pterm,
|
|
|
|
|
* which will construct exactly one such instance, and initialises
|
|
|
|
|
* this from the command line. */
|
|
|
|
|
extern char **pty_argv;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* gtkask.c.
|
|
|
|
|
*/
|
|
|
|
|
char *gtk_askpass_main(const char *display, const char *wintitle,
|
|
|
|
|
const char *prompt, bool *success);
|
|
|
|
|
|
Add a /proc/net magic authenticator.
This is a Linux-specific trick that I'm quite fond of: I've used it
before in 'agedu' and a lot of my unpublished personal scriptery.
Suppose you want to run a listening network server in such a way that
it can only accept connections from processes under your own control.
Often it's not convenient to do this by adding an authentication step
to the protocol itself (either because the password management gets
hairy or because the protocol is already well defined). The 'right'
answer is to switch from TCP to Unix-domain sockets, because then you
can use the file permissions on the path leading to the socket inode
to ensure that no other user id can connect to it - but that's often
inconvenient as well, because if any _client_ of the server is not
already prepared to speak AF_UNIX your control then you can only trick
it into connecting to an AF_UNIX socket instead of TCP by applying a
downstream patch or resorting to LD_PRELOAD shenanigans.
But on Linux, there's an alternative shenanigan available, in the form
of /proc/net/tcp (or tcp6), which lists every currently active TCP
endpoint known to the kernel, and for each one, lists an owning uid.
Listen on localhost only. Then, when a connection comes in, look up
the far end of it in that file and see if the owning uid is the right
one!
I've always vaguely wondered if there would be uses for this trick in
PuTTY. One potentially useful one might be to protect the listening
sockets created by local-to-remote port forwarding. But for the
moment, I'm only planning to use it for a less security-critical
purpose, which will appear in the next commit.
2019-03-31 08:24:17 +00:00
|
|
|
/*
|
|
|
|
|
* procnet.c.
|
|
|
|
|
*/
|
|
|
|
|
bool socket_peer_is_same_user(int fd);
|
|
|
|
|
static inline bool sk_peer_trusted(Socket *sock)
|
|
|
|
|
{
|
|
|
|
|
int fd = sk_net_get_fd(sock);
|
|
|
|
|
return fd >= 0 && socket_peer_is_same_user(fd);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
/*
|
|
|
|
|
* uxsftpserver.c.
|
|
|
|
|
*/
|
|
|
|
|
extern const SftpServerVtable unix_live_sftpserver_vt;
|
|
|
|
|
|
2019-02-07 18:21:06 +00:00
|
|
|
/*
|
|
|
|
|
* uxpoll.c.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct pollwrapper pollwrapper;
|
|
|
|
|
pollwrapper *pollwrap_new(void);
|
|
|
|
|
void pollwrap_free(pollwrapper *pw);
|
|
|
|
|
void pollwrap_clear(pollwrapper *pw);
|
|
|
|
|
void pollwrap_add_fd_events(pollwrapper *pw, int fd, int events);
|
|
|
|
|
void pollwrap_add_fd_rwx(pollwrapper *pw, int fd, int rwx);
|
|
|
|
|
int pollwrap_poll_instant(pollwrapper *pw);
|
|
|
|
|
int pollwrap_poll_endless(pollwrapper *pw);
|
|
|
|
|
int pollwrap_poll_timeout(pollwrapper *pw, int milliseconds);
|
|
|
|
|
int pollwrap_get_fd_events(pollwrapper *pw, int fd);
|
|
|
|
|
int pollwrap_get_fd_rwx(pollwrapper *pw, int fd);
|
|
|
|
|
static inline bool pollwrap_check_fd_rwx(pollwrapper *pw, int fd, int rwx)
|
|
|
|
|
{
|
|
|
|
|
return (pollwrap_get_fd_rwx(pw, fd) & rwx) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-07 19:14:32 +00:00
|
|
|
/*
|
|
|
|
|
* uxcliloop.c.
|
|
|
|
|
*/
|
|
|
|
|
typedef bool (*cliloop_pw_setup_t)(void *ctx, pollwrapper *pw);
|
|
|
|
|
typedef void (*cliloop_pw_check_t)(void *ctx, pollwrapper *pw);
|
|
|
|
|
typedef bool (*cliloop_continue_t)(void *ctx, bool found_any_fd,
|
|
|
|
|
bool ran_any_callback);
|
|
|
|
|
|
|
|
|
|
void cli_main_loop(cliloop_pw_setup_t pw_setup,
|
|
|
|
|
cliloop_pw_check_t pw_check,
|
|
|
|
|
cliloop_continue_t cont, void *ctx);
|
|
|
|
|
|
|
|
|
|
bool cliloop_no_pw_setup(void *ctx, pollwrapper *pw);
|
|
|
|
|
void cliloop_no_pw_check(void *ctx, pollwrapper *pw);
|
|
|
|
|
bool cliloop_always_continue(void *ctx, bool, bool);
|
|
|
|
|
|
2018-11-03 10:06:33 +00:00
|
|
|
#endif /* PUTTY_UNIX_H */
|