2002-10-31 22:49:52 +03:00
|
|
|
/*
|
|
|
|
|
* Unix networking abstraction.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
#include <errno.h>
|
|
|
|
|
#include <fcntl.h>
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
|
#include <sys/socket.h>
|
|
|
|
|
#include <sys/ioctl.h>
|
|
|
|
|
#include <arpa/inet.h>
|
|
|
|
|
#include <netinet/in.h>
|
|
|
|
|
#include <netinet/tcp.h>
|
|
|
|
|
#include <netdb.h>
|
2004-05-31 18:01:52 +04:00
|
|
|
#include <sys/un.h>
|
2015-05-18 15:57:45 +03:00
|
|
|
#include <pwd.h>
|
|
|
|
|
#include <grp.h>
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
#include "putty.h"
|
|
|
|
|
#include "network.h"
|
|
|
|
|
#include "tree234.h"
|
|
|
|
|
|
2005-04-25 22:51:15 +04:00
|
|
|
/* Solaris needs <sys/sockio.h> for SIOCATMARK. */
|
2005-05-06 02:47:30 +04:00
|
|
|
#ifndef SIOCATMARK
|
2005-04-25 22:51:15 +04:00
|
|
|
#include <sys/sockio.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2004-05-31 18:01:52 +04:00
|
|
|
#ifndef X11_UNIX_PATH
|
|
|
|
|
# define X11_UNIX_PATH "/tmp/.X11-unix/X"
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-08-07 02:12:05 +04:00
|
|
|
/*
|
|
|
|
|
* Access to sockaddr types without breaking C strict aliasing rules.
|
|
|
|
|
*/
|
|
|
|
|
union sockaddr_union {
|
|
|
|
|
struct sockaddr_storage storage;
|
|
|
|
|
struct sockaddr sa;
|
|
|
|
|
struct sockaddr_in sin;
|
2016-01-29 00:22:07 +03:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
struct sockaddr_in6 sin6;
|
|
|
|
|
#endif
|
2009-08-07 02:55:15 +04:00
|
|
|
struct sockaddr_un su;
|
2009-08-07 02:12:05 +04:00
|
|
|
};
|
|
|
|
|
|
2008-11-08 19:45:45 +03:00
|
|
|
/*
|
|
|
|
|
* Mutable state that goes with a SockAddr: stores information
|
|
|
|
|
* about where in the list of candidate IP(v*) addresses we've
|
|
|
|
|
* currently got to.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct SockAddrStep_tag SockAddrStep;
|
|
|
|
|
struct SockAddrStep_tag {
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
struct addrinfo *ai; /* steps along addr->ais */
|
|
|
|
|
#endif
|
|
|
|
|
int curraddr;
|
|
|
|
|
};
|
|
|
|
|
|
2018-05-27 11:29:33 +03:00
|
|
|
typedef struct NetSocket NetSocket;
|
|
|
|
|
struct NetSocket {
|
2003-05-04 18:18:18 +04:00
|
|
|
const char *error;
|
2002-10-31 22:49:52 +03:00
|
|
|
int s;
|
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 21:10:23 +03:00
|
|
|
Plug *plug;
|
2002-10-31 22:49:52 +03:00
|
|
|
bufchain output_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 22:23:19 +03:00
|
|
|
bool connected; /* irrelevant for listening sockets */
|
|
|
|
|
bool writable;
|
|
|
|
|
bool frozen; /* this causes readability notifications to be ignored */
|
|
|
|
|
bool localhost_only; /* for listening sockets */
|
2002-10-31 22:49:52 +03:00
|
|
|
char oobdata[1];
|
2019-02-06 23:42:44 +03:00
|
|
|
size_t sending_oob;
|
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 22:23:19 +03:00
|
|
|
bool oobpending; /* is there OOB data available to read? */
|
|
|
|
|
bool oobinline;
|
2011-09-13 15:44:03 +04:00
|
|
|
enum { EOF_NO, EOF_PENDING, EOF_SENT } outgoingeof;
|
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 22:23:19 +03:00
|
|
|
bool incomingeof;
|
2002-10-31 22:49:52 +03:00
|
|
|
int pending_error; /* in case send() returns error */
|
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 22:23:19 +03:00
|
|
|
bool listener;
|
|
|
|
|
bool nodelay, keepalive; /* for connect()-type sockets */
|
|
|
|
|
bool privport;
|
|
|
|
|
int port; /* and again */
|
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 21:10:23 +03:00
|
|
|
SockAddr *addr;
|
2008-11-08 19:45:45 +03:00
|
|
|
SockAddrStep step;
|
2008-08-21 02:21:04 +04:00
|
|
|
/*
|
|
|
|
|
* We sometimes need pairs of Socket structures to be linked:
|
|
|
|
|
* if we are listening on the same IPv6 and v4 port, for
|
|
|
|
|
* example. So here we define `parent' and `child' pointers to
|
|
|
|
|
* track this link.
|
|
|
|
|
*/
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *parent, *child;
|
|
|
|
|
|
2018-10-05 09:24:16 +03:00
|
|
|
Socket sock;
|
2002-10-31 22:49:52 +03: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 21:10:23 +03:00
|
|
|
struct SockAddr {
|
2008-11-08 19:58:55 +03:00
|
|
|
int refcount;
|
2003-05-04 18:18:18 +04:00
|
|
|
const char *error;
|
2008-11-08 19:45:45 +03:00
|
|
|
enum { UNRESOLVED, UNIX, IP } superfamily;
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2005-01-16 17:29:34 +03:00
|
|
|
struct addrinfo *ais; /* Addresses IPv6 style. */
|
2003-04-17 03:33:44 +04:00
|
|
|
#else
|
2005-01-16 17:29:34 +03:00
|
|
|
unsigned long *addresses; /* Addresses IPv4 style. */
|
2008-11-08 19:45:45 +03:00
|
|
|
int naddresses;
|
2002-10-31 22:49:52 +03:00
|
|
|
#endif
|
2002-12-18 19:23:11 +03:00
|
|
|
char hostname[512]; /* Store an unresolved host name. */
|
2002-10-31 22:49:52 +03:00
|
|
|
};
|
|
|
|
|
|
2008-11-08 19:45:45 +03:00
|
|
|
/*
|
|
|
|
|
* Which address family this address belongs to. AF_INET for IPv4;
|
|
|
|
|
* AF_INET6 for IPv6; AF_UNSPEC indicates that name resolution has
|
|
|
|
|
* not been done and a simple host name is held in this SockAddr
|
|
|
|
|
* structure.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
#define SOCKADDR_FAMILY(addr, step) \
|
|
|
|
|
((addr)->superfamily == UNRESOLVED ? AF_UNSPEC : \
|
|
|
|
|
(addr)->superfamily == UNIX ? AF_UNIX : \
|
|
|
|
|
(step).ai ? (step).ai->ai_family : AF_INET)
|
|
|
|
|
#else
|
2014-02-06 01:51:25 +04:00
|
|
|
/* Here we gratuitously reference 'step' to avoid gcc warnings about
|
|
|
|
|
* 'set but not used' when compiling -DNO_IPV6 */
|
2008-11-08 19:45:45 +03:00
|
|
|
#define SOCKADDR_FAMILY(addr, step) \
|
|
|
|
|
((addr)->superfamily == UNRESOLVED ? AF_UNSPEC : \
|
2014-02-06 01:51:25 +04:00
|
|
|
(addr)->superfamily == UNIX ? AF_UNIX : \
|
|
|
|
|
(step).curraddr ? AF_INET : AF_INET)
|
2008-11-08 19:45:45 +03:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Start a SockAddrStep structure to step through multiple
|
|
|
|
|
* addresses.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
#define START_STEP(addr, step) \
|
|
|
|
|
((step).ai = (addr)->ais, (step).curraddr = 0)
|
|
|
|
|
#else
|
|
|
|
|
#define START_STEP(addr, step) \
|
|
|
|
|
((step).curraddr = 0)
|
|
|
|
|
#endif
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
static tree234 *sktree;
|
|
|
|
|
|
2018-05-27 11:29:33 +03:00
|
|
|
static void uxsel_tell(NetSocket *s);
|
2003-03-29 19:47:06 +03:00
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
static int cmpfortree(void *av, void *bv)
|
|
|
|
|
{
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *a = (NetSocket *) av, *b = (NetSocket *) bv;
|
2002-10-31 22:49:52 +03:00
|
|
|
int as = a->s, bs = b->s;
|
|
|
|
|
if (as < bs)
|
|
|
|
|
return -1;
|
|
|
|
|
if (as > bs)
|
|
|
|
|
return +1;
|
2007-11-28 23:45:50 +03:00
|
|
|
if (a < b)
|
|
|
|
|
return -1;
|
|
|
|
|
if (a > b)
|
|
|
|
|
return +1;
|
2002-10-31 22:49:52 +03:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int cmpforsearch(void *av, void *bv)
|
|
|
|
|
{
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *b = (NetSocket *) bv;
|
2003-05-10 12:35:54 +04:00
|
|
|
int as = *(int *)av, bs = b->s;
|
2002-10-31 22:49:52 +03:00
|
|
|
if (as < bs)
|
|
|
|
|
return -1;
|
|
|
|
|
if (as > bs)
|
|
|
|
|
return +1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void sk_init(void)
|
|
|
|
|
{
|
|
|
|
|
sktree = newtree234(cmpfortree);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void sk_cleanup(void)
|
|
|
|
|
{
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *s;
|
2002-10-31 22:49:52 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (sktree) {
|
|
|
|
|
for (i = 0; (s = index234(sktree, i)) != NULL; i++) {
|
|
|
|
|
close(s->s);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
SockAddr *sk_namelookup(const char *host, char **canonicalname, int address_family)
|
2002-10-31 22:49:52 +03: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 21:10:23 +03:00
|
|
|
SockAddr *ret = snew(SockAddr);
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2003-04-17 03:33:44 +04:00
|
|
|
struct addrinfo hints;
|
|
|
|
|
int err;
|
|
|
|
|
#else
|
2002-10-31 22:49:52 +03:00
|
|
|
unsigned long a;
|
|
|
|
|
struct hostent *h = NULL;
|
2005-01-16 17:29:34 +03:00
|
|
|
int n;
|
2003-04-17 03:33:44 +04:00
|
|
|
#endif
|
2019-01-29 23:13:12 +03:00
|
|
|
strbuf *realhost = strbuf_new();
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
/* Clear the structure and default to IPv4. */
|
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 21:10:23 +03:00
|
|
|
memset(ret, 0, sizeof(SockAddr));
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->superfamily = UNRESOLVED;
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->error = NULL;
|
2008-11-08 19:58:55 +03:00
|
|
|
ret->refcount = 1;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2003-04-17 03:33:44 +04:00
|
|
|
hints.ai_flags = AI_CANONNAME;
|
2005-01-09 17:55:55 +03:00
|
|
|
hints.ai_family = (address_family == ADDRTYPE_IPV4 ? AF_INET :
|
|
|
|
|
address_family == ADDRTYPE_IPV6 ? AF_INET6 :
|
|
|
|
|
AF_UNSPEC);
|
|
|
|
|
hints.ai_socktype = SOCK_STREAM;
|
2003-04-17 03:33:44 +04:00
|
|
|
hints.ai_protocol = 0;
|
|
|
|
|
hints.ai_addrlen = 0;
|
|
|
|
|
hints.ai_addr = NULL;
|
|
|
|
|
hints.ai_canonname = NULL;
|
|
|
|
|
hints.ai_next = NULL;
|
2014-01-25 19:58:54 +04:00
|
|
|
{
|
|
|
|
|
char *trimmed_host = host_strduptrim(host); /* strip [] on literals */
|
|
|
|
|
err = getaddrinfo(trimmed_host, NULL, &hints, &ret->ais);
|
|
|
|
|
sfree(trimmed_host);
|
|
|
|
|
}
|
2003-04-17 03:33:44 +04:00
|
|
|
if (err != 0) {
|
|
|
|
|
ret->error = gai_strerror(err);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->superfamily = IP;
|
2018-12-01 12:35:52 +03:00
|
|
|
|
2008-11-08 19:45:45 +03:00
|
|
|
if (ret->ais->ai_canonname != NULL)
|
2018-12-01 12:35:52 +03:00
|
|
|
strbuf_catf(realhost, "%s", ret->ais->ai_canonname);
|
2003-04-17 03:33:44 +04:00
|
|
|
else
|
2018-12-01 12:35:52 +03:00
|
|
|
strbuf_catf(realhost, "%s", host);
|
2003-04-17 03:33:44 +04:00
|
|
|
#else
|
2005-01-14 22:28:18 +03:00
|
|
|
if ((a = inet_addr(host)) == (unsigned long)(in_addr_t)(-1)) {
|
2003-04-17 03:33:44 +04:00
|
|
|
/*
|
|
|
|
|
* Otherwise use the IPv4-only gethostbyname... (NOTE:
|
|
|
|
|
* we don't use gethostbyname as a fallback!)
|
|
|
|
|
*/
|
2008-11-08 19:45:45 +03:00
|
|
|
if (ret->superfamily == UNRESOLVED) {
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 23:32:31 +03:00
|
|
|
/*debug("Resolving \"%s\" with gethostbyname() (IPv4 only)...\n", host); */
|
2005-01-16 17:29:34 +03:00
|
|
|
if ( (h = gethostbyname(host)) )
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->superfamily = IP;
|
2003-04-17 03:33:44 +04:00
|
|
|
}
|
2008-11-08 19:45:45 +03:00
|
|
|
if (ret->superfamily == UNRESOLVED) {
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->error = (h_errno == HOST_NOT_FOUND ||
|
|
|
|
|
h_errno == NO_DATA ||
|
|
|
|
|
h_errno == NO_ADDRESS ? "Host does not exist" :
|
|
|
|
|
h_errno == TRY_AGAIN ?
|
|
|
|
|
"Temporary name service failure" :
|
|
|
|
|
"gethostbyname: unknown error");
|
2018-12-01 12:35:52 +03:00
|
|
|
strbuf_free(realhost);
|
2005-01-16 17:29:34 +03:00
|
|
|
return ret;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
2003-04-17 03:33:44 +04:00
|
|
|
/* This way we are always sure the h->h_name is valid :) */
|
2018-12-01 12:35:52 +03:00
|
|
|
realhost->len = 0;
|
|
|
|
|
strbuf_catf(realhost, "%s", h->h_name);
|
2005-01-16 17:29:34 +03:00
|
|
|
for (n = 0; h->h_addr_list[n]; n++);
|
|
|
|
|
ret->addresses = snewn(n, unsigned long);
|
|
|
|
|
ret->naddresses = n;
|
|
|
|
|
for (n = 0; n < ret->naddresses; n++) {
|
|
|
|
|
memcpy(&a, h->h_addr_list[n], sizeof(a));
|
|
|
|
|
ret->addresses[n] = ntohl(a);
|
|
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* This must be a numeric IPv4 address because it caused a
|
|
|
|
|
* success return from inet_addr.
|
|
|
|
|
*/
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->superfamily = IP;
|
2018-12-01 12:35:52 +03:00
|
|
|
realhost->len = 0;
|
|
|
|
|
strbuf_catf(realhost, "%s", host);
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->addresses = snew(unsigned long);
|
|
|
|
|
ret->naddresses = 1;
|
|
|
|
|
ret->addresses[0] = ntohl(a);
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
2003-04-17 03:33:44 +04:00
|
|
|
#endif
|
2018-12-01 12:35:52 +03:00
|
|
|
*canonicalname = strbuf_to_str(realhost);
|
2002-10-31 22:49:52 +03:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
SockAddr *sk_nonamelookup(const char *host)
|
2002-12-18 19:23:11 +03: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 21:10:23 +03:00
|
|
|
SockAddr *ret = snew(SockAddr);
|
2003-01-02 13:07:50 +03:00
|
|
|
ret->error = NULL;
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->superfamily = UNRESOLVED;
|
2002-12-18 19:23:11 +03:00
|
|
|
strncpy(ret->hostname, host, lenof(ret->hostname));
|
|
|
|
|
ret->hostname[lenof(ret->hostname)-1] = '\0';
|
2005-01-04 20:39:35 +03:00
|
|
|
#ifndef NO_IPV6
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->ais = NULL;
|
|
|
|
|
#else
|
|
|
|
|
ret->addresses = NULL;
|
2005-01-04 20:39:35 +03:00
|
|
|
#endif
|
2008-11-08 19:58:55 +03:00
|
|
|
ret->refcount = 1;
|
2002-12-18 19:23:11 +03:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
static bool sk_nextaddr(SockAddr *addr, SockAddrStep *step)
|
2005-01-16 17:29:34 +03:00
|
|
|
{
|
|
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
if (step->ai && step->ai->ai_next) {
|
|
|
|
|
step->ai = step->ai->ai_next;
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2005-01-16 17:29:34 +03:00
|
|
|
} else
|
2018-10-29 22:50:29 +03:00
|
|
|
return false;
|
2005-01-16 17:29:34 +03:00
|
|
|
#else
|
2008-11-08 19:45:45 +03:00
|
|
|
if (step->curraddr+1 < addr->naddresses) {
|
|
|
|
|
step->curraddr++;
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2005-01-16 17:29:34 +03:00
|
|
|
} else {
|
2018-10-29 22:50:29 +03:00
|
|
|
return false;
|
2005-01-16 17:29:34 +03:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
void sk_getaddr(SockAddr *addr, char *buf, int buflen)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2013-11-17 18:04:29 +04:00
|
|
|
if (addr->superfamily == UNRESOLVED || addr->superfamily == UNIX) {
|
2003-04-17 03:33:44 +04:00
|
|
|
strncpy(buf, addr->hostname, buflen);
|
|
|
|
|
buf[buflen-1] = '\0';
|
|
|
|
|
} else {
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
if (getnameinfo(addr->ais->ai_addr, addr->ais->ai_addrlen, buf, buflen,
|
2003-04-17 03:33:44 +04:00
|
|
|
NULL, 0, NI_NUMERICHOST) != 0) {
|
|
|
|
|
buf[0] = '\0';
|
|
|
|
|
strncat(buf, "<unknown>", buflen - 1);
|
|
|
|
|
}
|
|
|
|
|
#else
|
2002-10-31 22:49:52 +03:00
|
|
|
struct in_addr a;
|
2014-02-06 01:51:25 +04:00
|
|
|
SockAddrStep step;
|
|
|
|
|
START_STEP(addr, step);
|
|
|
|
|
assert(SOCKADDR_FAMILY(addr, step) == AF_INET);
|
2008-11-08 19:45:45 +03:00
|
|
|
a.s_addr = htonl(addr->addresses[0]);
|
2002-10-31 22:49:52 +03:00
|
|
|
strncpy(buf, inet_ntoa(a), buflen);
|
2002-12-18 19:23:11 +03:00
|
|
|
buf[buflen-1] = '\0';
|
2003-04-17 03:33:44 +04:00
|
|
|
#endif
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-28 13:56:19 +03:00
|
|
|
/*
|
|
|
|
|
* This constructs a SockAddr that points at one specific sub-address
|
|
|
|
|
* of a parent SockAddr. The returned SockAddr does not own all its
|
|
|
|
|
* own memory: it points into the old one's data structures, so it
|
|
|
|
|
* MUST NOT be used after the old one is freed, and it MUST NOT be
|
|
|
|
|
* passed to sk_addr_free. (The latter is why it's returned by value
|
|
|
|
|
* rather than dynamically allocated - that should clue in anyone
|
|
|
|
|
* writing a call to it that something is weird about it.)
|
|
|
|
|
*/
|
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 21:10:23 +03:00
|
|
|
static SockAddr sk_extractaddr_tmp(
|
|
|
|
|
SockAddr *addr, const SockAddrStep *step)
|
2017-01-28 13:56:19 +03: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 21:10:23 +03:00
|
|
|
SockAddr toret;
|
2017-01-28 13:56:19 +03:00
|
|
|
toret = *addr; /* structure copy */
|
|
|
|
|
toret.refcount = 1;
|
|
|
|
|
|
|
|
|
|
if (addr->superfamily == IP) {
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
toret.ais = step->ai;
|
|
|
|
|
#else
|
|
|
|
|
assert(SOCKADDR_FAMILY(addr, *step) == AF_INET);
|
|
|
|
|
toret.addresses += step->curraddr;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
bool sk_addr_needs_port(SockAddr *addr)
|
2013-11-17 18:05:41 +04:00
|
|
|
{
|
|
|
|
|
if (addr->superfamily == UNRESOLVED || addr->superfamily == UNIX) {
|
2018-10-29 22:50:29 +03:00
|
|
|
return false;
|
2013-11-17 18:05:41 +04:00
|
|
|
} else {
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2013-11-17 18:05:41 +04: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 22:23:19 +03:00
|
|
|
bool sk_hostname_is_local(const char *name)
|
2002-12-18 15:18:54 +03:00
|
|
|
{
|
2009-01-05 05:45:38 +03:00
|
|
|
return !strcmp(name, "localhost") ||
|
|
|
|
|
!strcmp(name, "::1") ||
|
|
|
|
|
!strncmp(name, "127.", 4);
|
2002-12-18 15:18:54 +03:00
|
|
|
}
|
|
|
|
|
|
2005-01-26 23:18:33 +03:00
|
|
|
#define ipv4_is_loopback(addr) \
|
|
|
|
|
(((addr).s_addr & htonl(0xff000000)) == htonl(0x7f000000))
|
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
static bool sockaddr_is_loopback(struct sockaddr *sa)
|
2005-01-26 23:18:33 +03:00
|
|
|
{
|
2009-08-07 02:12:05 +04:00
|
|
|
union sockaddr_union *u = (union sockaddr_union *)sa;
|
|
|
|
|
switch (u->sa.sa_family) {
|
2005-01-26 23:18:33 +03:00
|
|
|
case AF_INET:
|
2009-08-07 02:12:05 +04:00
|
|
|
return ipv4_is_loopback(u->sin.sin_addr);
|
2005-01-26 23:18:33 +03:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
case AF_INET6:
|
2009-08-07 02:12:05 +04:00
|
|
|
return IN6_IS_ADDR_LOOPBACK(&u->sin6.sin6_addr);
|
2005-01-26 23:18:33 +03:00
|
|
|
#endif
|
2005-01-28 14:47:33 +03:00
|
|
|
case AF_UNIX:
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2005-01-26 23:18:33 +03:00
|
|
|
default:
|
2018-10-29 22:50:29 +03:00
|
|
|
return false;
|
2005-01-26 23:18:33 +03: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 22:23:19 +03:00
|
|
|
bool sk_address_is_local(SockAddr *addr)
|
2002-12-18 15:18:54 +03:00
|
|
|
{
|
2008-11-08 19:45:45 +03:00
|
|
|
if (addr->superfamily == UNRESOLVED)
|
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 22:23:19 +03:00
|
|
|
return false; /* we don't know; assume not */
|
2009-01-06 02:36:14 +03:00
|
|
|
else if (addr->superfamily == 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 22:23:19 +03:00
|
|
|
return true;
|
2003-04-17 03:33:44 +04:00
|
|
|
else {
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
return sockaddr_is_loopback(addr->ais->ai_addr);
|
2003-04-17 03:33:44 +04:00
|
|
|
#else
|
2002-12-18 15:18:54 +03:00
|
|
|
struct in_addr a;
|
2014-02-06 01:51:25 +04:00
|
|
|
SockAddrStep step;
|
|
|
|
|
START_STEP(addr, step);
|
|
|
|
|
assert(SOCKADDR_FAMILY(addr, step) == AF_INET);
|
2008-11-08 19:45:45 +03:00
|
|
|
a.s_addr = htonl(addr->addresses[0]);
|
2002-12-18 15:18:54 +03:00
|
|
|
return ipv4_is_loopback(a);
|
2003-04-17 03:33:44 +04:00
|
|
|
#endif
|
2002-12-18 15:18:54 +03: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 22:23:19 +03:00
|
|
|
bool sk_address_is_special_local(SockAddr *addr)
|
2012-10-17 00:15:51 +04:00
|
|
|
{
|
|
|
|
|
return addr->superfamily == UNIX;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
int sk_addrtype(SockAddr *addr)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2014-02-06 01:51:25 +04:00
|
|
|
SockAddrStep step;
|
2008-11-08 19:45:45 +03:00
|
|
|
int family;
|
2014-02-06 01:51:25 +04:00
|
|
|
START_STEP(addr, step);
|
|
|
|
|
family = SOCKADDR_FAMILY(addr, step);
|
2008-11-08 19:45:45 +03:00
|
|
|
|
|
|
|
|
return (family == AF_INET ? ADDRTYPE_IPV4 :
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
family == AF_INET6 ? ADDRTYPE_IPV6 :
|
2002-12-18 19:23:11 +03:00
|
|
|
#endif
|
|
|
|
|
ADDRTYPE_NAME);
|
2002-10-31 22:49:52 +03: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 21:10:23 +03:00
|
|
|
void sk_addrcopy(SockAddr *addr, char *buf)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2008-11-08 19:45:45 +03:00
|
|
|
SockAddrStep step;
|
|
|
|
|
int family;
|
|
|
|
|
START_STEP(addr, step);
|
|
|
|
|
family = SOCKADDR_FAMILY(addr, step);
|
2003-04-17 03:33:44 +04:00
|
|
|
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
if (family == AF_INET)
|
|
|
|
|
memcpy(buf, &((struct sockaddr_in *)step.ai->ai_addr)->sin_addr,
|
2003-04-17 03:33:44 +04:00
|
|
|
sizeof(struct in_addr));
|
2008-11-08 19:45:45 +03:00
|
|
|
else if (family == AF_INET6)
|
|
|
|
|
memcpy(buf, &((struct sockaddr_in6 *)step.ai->ai_addr)->sin6_addr,
|
2003-04-17 03:33:44 +04:00
|
|
|
sizeof(struct in6_addr));
|
|
|
|
|
else
|
2019-01-03 11:12:19 +03:00
|
|
|
unreachable("bad address family in sk_addrcopy");
|
2003-04-17 03:33:44 +04:00
|
|
|
#else
|
|
|
|
|
struct in_addr a;
|
|
|
|
|
|
2008-11-08 19:45:45 +03:00
|
|
|
assert(family == AF_INET);
|
|
|
|
|
a.s_addr = htonl(addr->addresses[step.curraddr]);
|
2003-04-17 03:33:44 +04:00
|
|
|
memcpy(buf, (char*) &a.s_addr, 4);
|
2002-10-31 22:49:52 +03:00
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
void sk_addr_free(SockAddr *addr)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2008-11-08 19:58:55 +03:00
|
|
|
if (--addr->refcount > 0)
|
|
|
|
|
return;
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2005-01-16 17:29:34 +03:00
|
|
|
if (addr->ais != NULL)
|
|
|
|
|
freeaddrinfo(addr->ais);
|
|
|
|
|
#else
|
|
|
|
|
sfree(addr->addresses);
|
2003-04-17 03:33:44 +04:00
|
|
|
#endif
|
2002-10-31 22:49:52 +03:00
|
|
|
sfree(addr);
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
SockAddr *sk_addr_dup(SockAddr *addr)
|
2008-11-08 19:58:55 +03:00
|
|
|
{
|
|
|
|
|
addr->refcount++;
|
|
|
|
|
return addr;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
static Plug *sk_net_plug(Socket *sock, Plug *p)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
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 21:10:23 +03:00
|
|
|
Plug *ret = s->plug;
|
2002-10-31 22:49:52 +03:00
|
|
|
if (p)
|
|
|
|
|
s->plug = p;
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
static void sk_net_flush(Socket *s)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* We send data to the socket as soon as we can anyway,
|
|
|
|
|
* so we don't need to do anything here. :-)
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
static void sk_net_close(Socket *s);
|
2019-02-06 23:42:44 +03:00
|
|
|
static size_t sk_net_write(Socket *s, const void *data, size_t len);
|
|
|
|
|
static size_t sk_net_write_oob(Socket *s, const void *data, size_t len);
|
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 21:10:23 +03:00
|
|
|
static void sk_net_write_eof(Socket *s);
|
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 22:23:19 +03:00
|
|
|
static void sk_net_set_frozen(Socket *s, bool is_frozen);
|
2018-10-18 22:06:42 +03:00
|
|
|
static SocketPeerInfo *sk_net_peer_info(Socket *s);
|
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 21:10:23 +03:00
|
|
|
static const char *sk_net_socket_error(Socket *s);
|
2018-05-27 11:29:33 +03:00
|
|
|
|
2018-10-05 09:03:46 +03:00
|
|
|
static struct SocketVtable NetSocket_sockvt = {
|
2018-05-27 11:29:33 +03:00
|
|
|
sk_net_plug,
|
|
|
|
|
sk_net_close,
|
|
|
|
|
sk_net_write,
|
|
|
|
|
sk_net_write_oob,
|
|
|
|
|
sk_net_write_eof,
|
|
|
|
|
sk_net_flush,
|
|
|
|
|
sk_net_set_frozen,
|
|
|
|
|
sk_net_socket_error,
|
|
|
|
|
sk_net_peer_info,
|
2003-01-11 12:31:54 +03: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 21:10:23 +03:00
|
|
|
static Socket *sk_net_accept(accept_ctx_t ctx, Plug *plug)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2013-11-17 18:03:55 +04:00
|
|
|
int sockfd = ctx.i;
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *ret;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
/*
|
2018-05-27 11:29:33 +03:00
|
|
|
* Create NetSocket structure.
|
2002-10-31 22:49:52 +03:00
|
|
|
*/
|
2018-05-27 11:29:33 +03:00
|
|
|
ret = snew(NetSocket);
|
2018-10-05 09:24:16 +03:00
|
|
|
ret->sock.vt = &NetSocket_sockvt;
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->error = NULL;
|
|
|
|
|
ret->plug = plug;
|
|
|
|
|
bufchain_init(&ret->output_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 22:23:19 +03:00
|
|
|
ret->writable = true; /* to start with */
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->sending_oob = 0;
|
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 22:23:19 +03:00
|
|
|
ret->frozen = true;
|
|
|
|
|
ret->localhost_only = false; /* unused, but best init anyway */
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->pending_error = 0;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->oobpending = false;
|
2011-09-13 15:44:03 +04:00
|
|
|
ret->outgoingeof = EOF_NO;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->incomingeof = false;
|
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 22:23:19 +03:00
|
|
|
ret->listener = false;
|
2008-08-21 02:21:04 +04:00
|
|
|
ret->parent = ret->child = NULL;
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->addr = NULL;
|
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 22:23:19 +03:00
|
|
|
ret->connected = true;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2003-05-10 12:35:54 +04:00
|
|
|
ret->s = sockfd;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
if (ret->s < 0) {
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03: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 22:23:19 +03:00
|
|
|
ret->oobinline = false;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2003-03-29 19:47:06 +03:00
|
|
|
uxsel_tell(ret);
|
2002-10-31 22:49:52 +03:00
|
|
|
add234(sktree, ret);
|
|
|
|
|
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2018-05-27 11:29:33 +03:00
|
|
|
static int try_connect(NetSocket *sock)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
|
|
|
|
int s;
|
2009-08-07 02:55:15 +04:00
|
|
|
union sockaddr_union u;
|
|
|
|
|
const union sockaddr_union *sa;
|
2005-01-16 17:29:34 +03:00
|
|
|
int err = 0;
|
2002-10-31 22:49:52 +03:00
|
|
|
short localport;
|
2013-07-19 22:10:02 +04:00
|
|
|
int salen, family;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2007-11-28 23:45:50 +03:00
|
|
|
/*
|
|
|
|
|
* Remove the socket from the tree before we overwrite its
|
|
|
|
|
* internal socket id, because that forms part of the tree's
|
|
|
|
|
* sorting criterion. We'll add it back before exiting this
|
|
|
|
|
* function, whether we changed anything or not.
|
|
|
|
|
*/
|
|
|
|
|
del234(sktree, sock);
|
|
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
if (sock->s >= 0)
|
|
|
|
|
close(sock->s);
|
|
|
|
|
|
2017-01-28 13:56:19 +03: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 21:10:23 +03:00
|
|
|
SockAddr thisaddr = sk_extractaddr_tmp(
|
2017-01-28 13:56:19 +03:00
|
|
|
sock->addr, &sock->step);
|
|
|
|
|
plug_log(sock->plug, 0, &thisaddr, sock->port, NULL, 0);
|
|
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Open socket.
|
|
|
|
|
*/
|
2008-11-08 19:45:45 +03:00
|
|
|
family = SOCKADDR_FAMILY(sock->addr, sock->step);
|
|
|
|
|
assert(family != AF_UNSPEC);
|
|
|
|
|
s = socket(family, SOCK_STREAM, 0);
|
2005-01-16 17:29:34 +03:00
|
|
|
sock->s = s;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
if (s < 0) {
|
2005-01-16 17:29:34 +03:00
|
|
|
err = errno;
|
|
|
|
|
goto ret;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2006-12-09 18:44:31 +03:00
|
|
|
cloexec(s);
|
2006-11-23 17:32:11 +03:00
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
if (sock->oobinline) {
|
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 22:23:19 +03:00
|
|
|
int b = 1;
|
2013-07-19 21:45:01 +04:00
|
|
|
if (setsockopt(s, SOL_SOCKET, SO_OOBINLINE,
|
|
|
|
|
(void *) &b, sizeof(b)) < 0) {
|
|
|
|
|
err = errno;
|
|
|
|
|
close(s);
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
if (sock->nodelay) {
|
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 22:23:19 +03:00
|
|
|
int b = 1;
|
2013-07-19 21:45:01 +04:00
|
|
|
if (setsockopt(s, IPPROTO_TCP, TCP_NODELAY,
|
|
|
|
|
(void *) &b, sizeof(b)) < 0) {
|
|
|
|
|
err = errno;
|
|
|
|
|
close(s);
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
if (sock->keepalive) {
|
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 22:23:19 +03:00
|
|
|
int b = 1;
|
2013-07-19 21:45:01 +04:00
|
|
|
if (setsockopt(s, SOL_SOCKET, SO_KEEPALIVE,
|
|
|
|
|
(void *) &b, sizeof(b)) < 0) {
|
|
|
|
|
err = errno;
|
|
|
|
|
close(s);
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2004-06-20 21:07:38 +04:00
|
|
|
}
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
/*
|
|
|
|
|
* Bind to local address.
|
|
|
|
|
*/
|
2005-01-16 17:29:34 +03:00
|
|
|
if (sock->privport)
|
2002-10-31 22:49:52 +03:00
|
|
|
localport = 1023; /* count from 1023 downwards */
|
|
|
|
|
else
|
|
|
|
|
localport = 0; /* just use port 0 (ie kernel picks) */
|
|
|
|
|
|
2004-02-03 17:47:43 +03:00
|
|
|
/* BSD IP stacks need sockaddr_in zeroed before filling in */
|
2009-08-07 02:55:15 +04:00
|
|
|
memset(&u,'\0',sizeof(u));
|
2004-05-31 18:01:52 +04:00
|
|
|
|
|
|
|
|
/* We don't try to bind to a local address for UNIX domain sockets. (Why
|
|
|
|
|
* do we bother doing the bind when localport == 0 anyway?) */
|
2008-11-08 19:45:45 +03:00
|
|
|
if (family != AF_UNIX) {
|
2004-05-31 18:01:52 +04:00
|
|
|
/* Loop round trying to bind */
|
|
|
|
|
while (1) {
|
|
|
|
|
int retcode;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
if (family == AF_INET6) {
|
2004-05-31 18:01:52 +04:00
|
|
|
/* XXX use getaddrinfo to get a local address? */
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin6.sin6_family = AF_INET6;
|
|
|
|
|
u.sin6.sin6_addr = in6addr_any;
|
|
|
|
|
u.sin6.sin6_port = htons(localport);
|
|
|
|
|
retcode = bind(s, &u.sa, sizeof(u.sin6));
|
2004-05-31 18:01:52 +04:00
|
|
|
} else
|
2002-10-31 22:49:52 +03:00
|
|
|
#endif
|
2004-05-31 18:01:52 +04:00
|
|
|
{
|
2008-11-08 19:45:45 +03:00
|
|
|
assert(family == AF_INET);
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin.sin_family = AF_INET;
|
|
|
|
|
u.sin.sin_addr.s_addr = htonl(INADDR_ANY);
|
|
|
|
|
u.sin.sin_port = htons(localport);
|
|
|
|
|
retcode = bind(s, &u.sa, sizeof(u.sin));
|
2004-05-31 18:01:52 +04:00
|
|
|
}
|
|
|
|
|
if (retcode >= 0) {
|
|
|
|
|
err = 0;
|
|
|
|
|
break; /* done */
|
|
|
|
|
} else {
|
|
|
|
|
err = errno;
|
|
|
|
|
if (err != EADDRINUSE) /* failed, for a bad reason */
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (localport == 0)
|
|
|
|
|
break; /* we're only looping once */
|
|
|
|
|
localport--;
|
|
|
|
|
if (localport == 0)
|
|
|
|
|
break; /* we might have got to the end */
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
2004-05-31 18:01:52 +04:00
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
if (err)
|
|
|
|
|
goto ret;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Connect to remote address.
|
|
|
|
|
*/
|
2008-11-08 19:45:45 +03:00
|
|
|
switch(family) {
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2004-05-31 18:01:52 +04:00
|
|
|
case AF_INET:
|
|
|
|
|
/* XXX would be better to have got getaddrinfo() to fill in the port. */
|
2008-11-08 19:45:45 +03:00
|
|
|
((struct sockaddr_in *)sock->step.ai->ai_addr)->sin_port =
|
2005-01-16 17:29:34 +03:00
|
|
|
htons(sock->port);
|
2009-08-07 02:55:15 +04:00
|
|
|
sa = (const union sockaddr_union *)sock->step.ai->ai_addr;
|
2008-11-08 19:45:45 +03:00
|
|
|
salen = sock->step.ai->ai_addrlen;
|
2004-05-31 18:01:52 +04:00
|
|
|
break;
|
|
|
|
|
case AF_INET6:
|
2008-11-08 19:45:45 +03:00
|
|
|
((struct sockaddr_in *)sock->step.ai->ai_addr)->sin_port =
|
2005-01-16 17:29:34 +03:00
|
|
|
htons(sock->port);
|
2009-08-07 02:55:15 +04:00
|
|
|
sa = (const union sockaddr_union *)sock->step.ai->ai_addr;
|
2008-11-08 19:45:45 +03:00
|
|
|
salen = sock->step.ai->ai_addrlen;
|
2004-05-31 18:01:52 +04:00
|
|
|
break;
|
2003-04-17 03:33:44 +04:00
|
|
|
#else
|
2004-05-31 18:01:52 +04:00
|
|
|
case AF_INET:
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin.sin_family = AF_INET;
|
|
|
|
|
u.sin.sin_addr.s_addr = htonl(sock->addr->addresses[sock->step.curraddr]);
|
|
|
|
|
u.sin.sin_port = htons((short) sock->port);
|
|
|
|
|
sa = &u;
|
|
|
|
|
salen = sizeof u.sin;
|
2004-05-31 18:01:52 +04:00
|
|
|
break;
|
2003-04-17 03:33:44 +04:00
|
|
|
#endif
|
2004-05-31 18:01:52 +04:00
|
|
|
case AF_UNIX:
|
2005-01-16 17:29:34 +03:00
|
|
|
assert(sock->port == 0); /* to catch confused people */
|
2009-08-07 02:55:15 +04:00
|
|
|
assert(strlen(sock->addr->hostname) < sizeof u.su.sun_path);
|
|
|
|
|
u.su.sun_family = AF_UNIX;
|
|
|
|
|
strcpy(u.su.sun_path, sock->addr->hostname);
|
|
|
|
|
sa = &u;
|
|
|
|
|
salen = sizeof u.su;
|
2004-05-31 18:01:52 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
2019-01-03 11:12:19 +03:00
|
|
|
unreachable("unknown address family");
|
2005-04-24 18:43:00 +04:00
|
|
|
exit(1); /* XXX: GCC doesn't understand assert() on some systems. */
|
2004-05-31 18:01:52 +04:00
|
|
|
}
|
2003-04-17 03:58:59 +04:00
|
|
|
|
2013-07-19 22:10:02 +04:00
|
|
|
nonblock(s);
|
2003-01-09 21:14:24 +03:00
|
|
|
|
2009-08-07 02:55:15 +04:00
|
|
|
if ((connect(s, &(sa->sa), salen)) < 0) {
|
2003-01-09 21:14:24 +03:00
|
|
|
if ( errno != EINPROGRESS ) {
|
2005-01-16 17:29:34 +03:00
|
|
|
err = errno;
|
|
|
|
|
goto ret;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* If we _don't_ get EWOULDBLOCK, the connect has completed
|
|
|
|
|
* and we should set the socket as connected and writable.
|
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
sock->connected = true;
|
|
|
|
|
sock->writable = true;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
uxsel_tell(sock);
|
|
|
|
|
|
|
|
|
|
ret:
|
2007-11-28 23:45:50 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* No matter what happened, put the socket back in the tree.
|
|
|
|
|
*/
|
|
|
|
|
add234(sktree, sock);
|
|
|
|
|
|
2017-01-28 13:56:19 +03:00
|
|
|
if (err) {
|
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 21:10:23 +03:00
|
|
|
SockAddr thisaddr = sk_extractaddr_tmp(
|
2017-01-28 13:56:19 +03:00
|
|
|
sock->addr, &sock->step);
|
|
|
|
|
plug_log(sock->plug, 1, &thisaddr, sock->port, strerror(err), err);
|
|
|
|
|
}
|
2005-01-16 17:29:34 +03:00
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
Socket *sk_new(SockAddr *addr, int port, bool privport, bool oobinline,
|
|
|
|
|
bool nodelay, bool keepalive, Plug *plug)
|
2005-01-16 17:29:34 +03:00
|
|
|
{
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *ret;
|
2005-01-16 17:29:34 +03:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/*
|
2018-05-27 11:29:33 +03:00
|
|
|
* Create NetSocket structure.
|
2005-01-16 17:29:34 +03:00
|
|
|
*/
|
2018-05-27 11:29:33 +03:00
|
|
|
ret = snew(NetSocket);
|
2018-10-05 09:24:16 +03:00
|
|
|
ret->sock.vt = &NetSocket_sockvt;
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->error = NULL;
|
|
|
|
|
ret->plug = plug;
|
|
|
|
|
bufchain_init(&ret->output_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 22:23:19 +03:00
|
|
|
ret->connected = false; /* to start with */
|
|
|
|
|
ret->writable = false; /* to start with */
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->sending_oob = 0;
|
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 22:23:19 +03:00
|
|
|
ret->frozen = false;
|
|
|
|
|
ret->localhost_only = false; /* unused, but best init anyway */
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->pending_error = 0;
|
2008-08-21 02:21:04 +04:00
|
|
|
ret->parent = ret->child = NULL;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->oobpending = false;
|
2011-09-13 15:44:03 +04:00
|
|
|
ret->outgoingeof = EOF_NO;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->incomingeof = false;
|
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 22:23:19 +03:00
|
|
|
ret->listener = false;
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->addr = addr;
|
2008-11-08 19:45:45 +03:00
|
|
|
START_STEP(ret->addr, ret->step);
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->s = -1;
|
|
|
|
|
ret->oobinline = oobinline;
|
|
|
|
|
ret->nodelay = nodelay;
|
|
|
|
|
ret->keepalive = keepalive;
|
|
|
|
|
ret->privport = privport;
|
|
|
|
|
ret->port = port;
|
|
|
|
|
|
|
|
|
|
do {
|
|
|
|
|
err = try_connect(ret);
|
2008-11-08 19:45:45 +03:00
|
|
|
} while (err && sk_nextaddr(ret->addr, &ret->step));
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
if (err)
|
|
|
|
|
ret->error = strerror(err);
|
2003-08-07 20:04:33 +04:00
|
|
|
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03: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 21:10:23 +03:00
|
|
|
Socket *sk_newlistener(const char *srcaddr, int port, Plug *plug,
|
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 22:23:19 +03:00
|
|
|
bool local_host_only, int orig_address_family)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
|
|
|
|
int s;
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2014-12-20 19:54:28 +03:00
|
|
|
struct addrinfo hints, *ai = NULL;
|
2003-04-17 03:33:44 +04:00
|
|
|
char portstr[6];
|
2002-10-31 22:49:52 +03:00
|
|
|
#endif
|
2009-08-07 02:55:15 +04:00
|
|
|
union sockaddr_union u;
|
|
|
|
|
union sockaddr_union *addr;
|
2005-01-16 15:37:19 +03:00
|
|
|
int addrlen;
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *ret;
|
2002-10-31 22:49:52 +03:00
|
|
|
int retcode;
|
2008-08-21 02:21:04 +04:00
|
|
|
int address_family;
|
2002-10-31 22:49:52 +03:00
|
|
|
int on = 1;
|
|
|
|
|
|
|
|
|
|
/*
|
2018-05-27 11:29:33 +03:00
|
|
|
* Create NetSocket structure.
|
2002-10-31 22:49:52 +03:00
|
|
|
*/
|
2018-05-27 11:29:33 +03:00
|
|
|
ret = snew(NetSocket);
|
2018-10-05 09:24:16 +03:00
|
|
|
ret->sock.vt = &NetSocket_sockvt;
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->error = NULL;
|
|
|
|
|
ret->plug = plug;
|
|
|
|
|
bufchain_init(&ret->output_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 22:23:19 +03:00
|
|
|
ret->writable = false; /* to start with */
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->sending_oob = 0;
|
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 22:23:19 +03:00
|
|
|
ret->frozen = false;
|
2002-10-31 22:49:52 +03:00
|
|
|
ret->localhost_only = local_host_only;
|
|
|
|
|
ret->pending_error = 0;
|
2008-08-21 02:21:04 +04:00
|
|
|
ret->parent = ret->child = NULL;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->oobpending = false;
|
2011-09-13 15:44:03 +04:00
|
|
|
ret->outgoingeof = EOF_NO;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->incomingeof = false;
|
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 22:23:19 +03:00
|
|
|
ret->listener = true;
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->addr = NULL;
|
2013-11-17 18:04:33 +04:00
|
|
|
ret->s = -1;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2004-12-30 19:45:11 +03:00
|
|
|
/*
|
|
|
|
|
* Translate address_family from platform-independent constants
|
|
|
|
|
* into local reality.
|
|
|
|
|
*/
|
2008-08-21 02:21:04 +04:00
|
|
|
address_family = (orig_address_family == ADDRTYPE_IPV4 ? AF_INET :
|
2005-09-13 23:54:01 +04:00
|
|
|
#ifndef NO_IPV6
|
2008-08-21 02:21:04 +04:00
|
|
|
orig_address_family == ADDRTYPE_IPV6 ? AF_INET6 :
|
2005-09-13 23:54:01 +04:00
|
|
|
#endif
|
|
|
|
|
AF_UNSPEC);
|
2004-12-30 19:45:11 +03:00
|
|
|
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
/* Let's default to IPv6.
|
|
|
|
|
* If the stack doesn't support IPv6, we will fall back to IPv4. */
|
|
|
|
|
if (address_family == AF_UNSPEC) address_family = AF_INET6;
|
|
|
|
|
#else
|
|
|
|
|
/* No other choice, default to IPv4 */
|
|
|
|
|
if (address_family == AF_UNSPEC) address_family = AF_INET;
|
|
|
|
|
#endif
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
/*
|
|
|
|
|
* Open socket.
|
|
|
|
|
*/
|
2004-12-30 19:45:11 +03:00
|
|
|
s = socket(address_family, SOCK_STREAM, 0);
|
|
|
|
|
|
2005-09-13 23:54:01 +04:00
|
|
|
#ifndef NO_IPV6
|
2004-12-30 19:45:11 +03:00
|
|
|
/* If the host doesn't support IPv6 try fallback to IPv4. */
|
|
|
|
|
if (s < 0 && address_family == AF_INET6) {
|
|
|
|
|
address_family = AF_INET;
|
|
|
|
|
s = socket(address_family, SOCK_STREAM, 0);
|
|
|
|
|
}
|
2005-09-13 23:54:01 +04:00
|
|
|
#endif
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
if (s < 0) {
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2006-12-09 18:44:31 +03:00
|
|
|
cloexec(s);
|
2006-11-23 17:32:11 +03: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 22:23:19 +03:00
|
|
|
ret->oobinline = false;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2013-07-19 21:45:01 +04:00
|
|
|
if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,
|
|
|
|
|
(const char *)&on, sizeof(on)) < 0) {
|
|
|
|
|
ret->error = strerror(errno);
|
|
|
|
|
close(s);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2013-07-19 21:45:01 +04:00
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2005-01-16 15:37:19 +03:00
|
|
|
retcode = -1;
|
|
|
|
|
addr = NULL; addrlen = -1; /* placate optimiser */
|
|
|
|
|
|
|
|
|
|
if (srcaddr != NULL) {
|
2004-12-30 19:45:11 +03:00
|
|
|
#ifndef NO_IPV6
|
2005-01-16 15:37:19 +03:00
|
|
|
hints.ai_flags = AI_NUMERICHOST;
|
|
|
|
|
hints.ai_family = address_family;
|
2005-01-22 18:32:10 +03:00
|
|
|
hints.ai_socktype = SOCK_STREAM;
|
2005-01-16 15:37:19 +03:00
|
|
|
hints.ai_protocol = 0;
|
|
|
|
|
hints.ai_addrlen = 0;
|
|
|
|
|
hints.ai_addr = NULL;
|
|
|
|
|
hints.ai_canonname = NULL;
|
|
|
|
|
hints.ai_next = NULL;
|
2005-01-27 02:49:56 +03:00
|
|
|
assert(port >= 0 && port <= 99999);
|
2005-01-16 15:37:19 +03:00
|
|
|
sprintf(portstr, "%d", port);
|
2014-01-25 19:58:54 +04:00
|
|
|
{
|
|
|
|
|
char *trimmed_addr = host_strduptrim(srcaddr);
|
|
|
|
|
retcode = getaddrinfo(trimmed_addr, portstr, &hints, &ai);
|
|
|
|
|
sfree(trimmed_addr);
|
|
|
|
|
}
|
2005-01-22 18:20:35 +03:00
|
|
|
if (retcode == 0) {
|
2009-08-07 02:55:15 +04:00
|
|
|
addr = (union sockaddr_union *)ai->ai_addr;
|
2005-01-22 18:19:21 +03:00
|
|
|
addrlen = ai->ai_addrlen;
|
|
|
|
|
}
|
2005-01-16 15:37:19 +03:00
|
|
|
#else
|
2009-08-07 02:55:15 +04:00
|
|
|
memset(&u,'\0',sizeof u);
|
|
|
|
|
u.sin.sin_family = AF_INET;
|
|
|
|
|
u.sin.sin_port = htons(port);
|
|
|
|
|
u.sin.sin_addr.s_addr = inet_addr(srcaddr);
|
|
|
|
|
if (u.sin.sin_addr.s_addr != (in_addr_t)(-1)) {
|
2005-01-16 15:37:19 +03:00
|
|
|
/* Override localhost_only with specified listen addr. */
|
2009-08-07 02:55:15 +04:00
|
|
|
ret->localhost_only = ipv4_is_loopback(u.sin.sin_addr);
|
2005-01-16 15:37:19 +03:00
|
|
|
}
|
2009-08-07 02:55:15 +04:00
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.sin);
|
2005-01-16 15:37:19 +03:00
|
|
|
retcode = 0;
|
2002-10-31 22:49:52 +03:00
|
|
|
#endif
|
2005-01-16 15:37:19 +03:00
|
|
|
}
|
2002-12-18 14:39:25 +03:00
|
|
|
|
2005-01-16 15:37:19 +03:00
|
|
|
if (retcode != 0) {
|
2009-08-07 02:55:15 +04:00
|
|
|
memset(&u,'\0',sizeof u);
|
2005-01-16 15:37:19 +03:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
if (address_family == AF_INET6) {
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin6.sin6_family = AF_INET6;
|
|
|
|
|
u.sin6.sin6_port = htons(port);
|
2005-01-16 15:37:19 +03:00
|
|
|
if (local_host_only)
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin6.sin6_addr = in6addr_loopback;
|
2005-01-16 15:37:19 +03:00
|
|
|
else
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin6.sin6_addr = in6addr_any;
|
|
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.sin6);
|
2005-01-16 15:37:19 +03:00
|
|
|
} else
|
|
|
|
|
#endif
|
|
|
|
|
{
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin.sin_family = AF_INET;
|
|
|
|
|
u.sin.sin_port = htons(port);
|
2002-12-18 14:39:25 +03:00
|
|
|
if (local_host_only)
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
|
2002-12-18 14:39:25 +03:00
|
|
|
else
|
2009-08-07 02:55:15 +04:00
|
|
|
u.sin.sin_addr.s_addr = htonl(INADDR_ANY);
|
|
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.sin);
|
2005-01-16 15:37:19 +03:00
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2009-08-07 02:55:15 +04:00
|
|
|
retcode = bind(s, &addr->sa, addrlen);
|
2014-12-20 19:54:28 +03:00
|
|
|
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
if (ai)
|
|
|
|
|
freeaddrinfo(ai);
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-01-16 15:37:19 +03:00
|
|
|
if (retcode < 0) {
|
|
|
|
|
close(s);
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (listen(s, SOMAXCONN) < 0) {
|
|
|
|
|
close(s);
|
2005-01-16 17:29:34 +03:00
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2008-08-21 02:21:04 +04:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
/*
|
|
|
|
|
* If we were given ADDRTYPE_UNSPEC, we must also create an
|
|
|
|
|
* IPv4 listening socket and link it to this one.
|
|
|
|
|
*/
|
|
|
|
|
if (address_family == AF_INET6 && orig_address_family == ADDRTYPE_UNSPEC) {
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *other;
|
2008-08-21 02:21:04 +04:00
|
|
|
|
2018-10-06 01:49:08 +03:00
|
|
|
other = container_of(
|
2018-05-27 11:29:33 +03:00
|
|
|
sk_newlistener(srcaddr, port, plug,
|
|
|
|
|
local_host_only, ADDRTYPE_IPV4),
|
2018-10-05 09:24:16 +03:00
|
|
|
NetSocket, sock);
|
2008-08-21 02:21:04 +04:00
|
|
|
|
|
|
|
|
if (other) {
|
|
|
|
|
if (!other->error) {
|
|
|
|
|
other->parent = ret;
|
|
|
|
|
ret->child = other;
|
|
|
|
|
} else {
|
|
|
|
|
/* If we couldn't create a listening socket on IPv4 as well
|
|
|
|
|
* as IPv6, we must return an error overall. */
|
|
|
|
|
close(s);
|
|
|
|
|
sfree(ret);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &other->sock;
|
2008-08-21 02:21:04 +04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-01-16 15:37:19 +03:00
|
|
|
ret->s = s;
|
|
|
|
|
|
2003-03-29 19:47:06 +03:00
|
|
|
uxsel_tell(ret);
|
2002-10-31 22:49:52 +03:00
|
|
|
add234(sktree, ret);
|
|
|
|
|
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2002-10-31 22:49:52 +03: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 21:10:23 +03:00
|
|
|
static void sk_net_close(Socket *sock)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2008-08-21 02:21:04 +04:00
|
|
|
if (s->child)
|
2018-10-05 09:24:16 +03:00
|
|
|
sk_net_close(&s->child->sock);
|
2008-08-21 02:21:04 +04:00
|
|
|
|
2019-01-29 23:13:47 +03:00
|
|
|
bufchain_clear(&s->output_data);
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
del234(sktree, s);
|
2017-10-01 23:05:25 +03:00
|
|
|
if (s->s >= 0) {
|
|
|
|
|
uxsel_del(s->s);
|
|
|
|
|
close(s->s);
|
|
|
|
|
}
|
2005-01-16 17:29:34 +03:00
|
|
|
if (s->addr)
|
|
|
|
|
sk_addr_free(s->addr);
|
2019-01-29 23:15:43 +03:00
|
|
|
delete_callbacks_for_context(s);
|
2002-10-31 22:49:52 +03:00
|
|
|
sfree(s);
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
void *sk_getxdmdata(Socket *sock, int *lenp)
|
2003-01-11 12:31:54 +03:00
|
|
|
{
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *s;
|
2009-08-07 02:12:05 +04:00
|
|
|
union sockaddr_union u;
|
2003-01-11 12:31:54 +03:00
|
|
|
socklen_t addrlen;
|
2005-01-28 14:39:45 +03:00
|
|
|
char *buf;
|
|
|
|
|
static unsigned int unix_addr = 0xFFFFFFFF;
|
2003-01-11 12:31:54 +03:00
|
|
|
|
|
|
|
|
/*
|
2018-05-27 11:29:33 +03:00
|
|
|
* We must check that this socket really _is_ a NetSocket before
|
|
|
|
|
* downcasting it.
|
2003-01-11 12:31:54 +03:00
|
|
|
*/
|
2018-10-05 09:24:16 +03:00
|
|
|
if (sock->vt != &NetSocket_sockvt)
|
2005-01-28 14:39:45 +03:00
|
|
|
return NULL; /* failure */
|
2018-10-06 01:49:08 +03:00
|
|
|
s = container_of(sock, NetSocket, sock);
|
2003-01-11 12:31:54 +03:00
|
|
|
|
2009-08-07 02:12:05 +04:00
|
|
|
addrlen = sizeof(u);
|
|
|
|
|
if (getsockname(s->s, &u.sa, &addrlen) < 0)
|
2005-01-28 14:39:45 +03:00
|
|
|
return NULL;
|
2009-08-07 02:12:05 +04:00
|
|
|
switch(u.sa.sa_family) {
|
2004-05-31 18:01:52 +04:00
|
|
|
case AF_INET:
|
2005-01-28 14:39:45 +03:00
|
|
|
*lenp = 6;
|
|
|
|
|
buf = snewn(*lenp, char);
|
2009-08-07 02:12:05 +04:00
|
|
|
PUT_32BIT_MSB_FIRST(buf, ntohl(u.sin.sin_addr.s_addr));
|
|
|
|
|
PUT_16BIT_MSB_FIRST(buf+4, ntohs(u.sin.sin_port));
|
2004-05-31 18:01:52 +04:00
|
|
|
break;
|
2005-01-28 14:39:45 +03:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
case AF_INET6:
|
|
|
|
|
*lenp = 6;
|
|
|
|
|
buf = snewn(*lenp, char);
|
2009-08-07 02:12:05 +04:00
|
|
|
if (IN6_IS_ADDR_V4MAPPED(&u.sin6.sin6_addr)) {
|
|
|
|
|
memcpy(buf, u.sin6.sin6_addr.s6_addr + 12, 4);
|
|
|
|
|
PUT_16BIT_MSB_FIRST(buf+4, ntohs(u.sin6.sin6_port));
|
2005-01-28 14:39:45 +03:00
|
|
|
} else
|
|
|
|
|
/* This is stupid, but it's what XLib does. */
|
|
|
|
|
memset(buf, 0, 6);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2004-05-31 18:01:52 +04:00
|
|
|
case AF_UNIX:
|
2005-01-28 14:39:45 +03:00
|
|
|
*lenp = 6;
|
|
|
|
|
buf = snewn(*lenp, char);
|
|
|
|
|
PUT_32BIT_MSB_FIRST(buf, unix_addr--);
|
|
|
|
|
PUT_16BIT_MSB_FIRST(buf+4, getpid());
|
2004-05-31 18:01:52 +04:00
|
|
|
break;
|
2003-01-11 12:31:54 +03:00
|
|
|
|
2004-05-31 18:01:52 +04:00
|
|
|
/* XXX IPV6 */
|
|
|
|
|
|
|
|
|
|
default:
|
2005-01-28 14:39:45 +03:00
|
|
|
return NULL;
|
2004-05-31 18:01:52 +04:00
|
|
|
}
|
2003-01-11 12:31:54 +03:00
|
|
|
|
2005-01-28 14:39:45 +03:00
|
|
|
return buf;
|
2003-01-11 12:31:54 +03:00
|
|
|
}
|
|
|
|
|
|
2013-08-17 20:06:27 +04:00
|
|
|
/*
|
|
|
|
|
* Deal with socket errors detected in try_send().
|
|
|
|
|
*/
|
|
|
|
|
static void socket_error_callback(void *vs)
|
|
|
|
|
{
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *s = (NetSocket *)vs;
|
2013-08-17 20:06:27 +04:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Just in case other socket work has caused this socket to vanish
|
|
|
|
|
* or become somehow non-erroneous before this callback arrived...
|
|
|
|
|
*/
|
|
|
|
|
if (!find234(sktree, s, NULL) || !s->pending_error)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* An error has occurred on this socket. Pass it to the plug.
|
|
|
|
|
*/
|
|
|
|
|
plug_closing(s->plug, strerror(s->pending_error), s->pending_error, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
/*
|
|
|
|
|
* The function which tries to send on a socket once it's deemed
|
|
|
|
|
* writable.
|
|
|
|
|
*/
|
2018-05-27 11:29:33 +03:00
|
|
|
void try_send(NetSocket *s)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
|
|
|
|
while (s->sending_oob || bufchain_size(&s->output_data) > 0) {
|
|
|
|
|
int nsent;
|
|
|
|
|
int err;
|
2019-02-06 23:46:45 +03:00
|
|
|
const void *data;
|
2019-02-06 23:42:44 +03:00
|
|
|
size_t len;
|
|
|
|
|
int urgentflag;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
if (s->sending_oob) {
|
|
|
|
|
urgentflag = MSG_OOB;
|
|
|
|
|
len = s->sending_oob;
|
|
|
|
|
data = &s->oobdata;
|
|
|
|
|
} else {
|
|
|
|
|
urgentflag = 0;
|
2019-02-06 23:46:45 +03:00
|
|
|
ptrlen bufdata = bufchain_prefix(&s->output_data);
|
|
|
|
|
data = bufdata.ptr;
|
|
|
|
|
len = bufdata.len;
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
nsent = send(s->s, data, len, urgentflag);
|
2019-01-22 21:25:54 +03:00
|
|
|
noise_ultralight(NOISE_SOURCE_IOLEN, nsent);
|
2002-10-31 22:49:52 +03:00
|
|
|
if (nsent <= 0) {
|
|
|
|
|
err = (nsent < 0 ? errno : 0);
|
|
|
|
|
if (err == EWOULDBLOCK) {
|
|
|
|
|
/*
|
|
|
|
|
* Perfectly normal: we've sent all we can for the moment.
|
|
|
|
|
*/
|
2018-10-29 22:50:29 +03:00
|
|
|
s->writable = false;
|
2002-10-31 22:49:52 +03:00
|
|
|
return;
|
2005-02-23 02:30:09 +03:00
|
|
|
} else {
|
2002-10-31 22:49:52 +03:00
|
|
|
/*
|
2005-02-23 02:30:09 +03:00
|
|
|
* We unfortunately can't just call plug_closing(),
|
2002-10-31 22:49:52 +03:00
|
|
|
* because it's quite likely that we're currently
|
|
|
|
|
* _in_ a call from the code we'd be calling back
|
|
|
|
|
* to, so we'd have to make half the SSH code
|
|
|
|
|
* reentrant. Instead we flag a pending error on
|
|
|
|
|
* the socket, to be dealt with (by calling
|
|
|
|
|
* plug_closing()) at some suitable future moment.
|
|
|
|
|
*/
|
|
|
|
|
s->pending_error = err;
|
2011-12-08 23:15:57 +04:00
|
|
|
/*
|
|
|
|
|
* Immediately cease selecting on this socket, so that
|
|
|
|
|
* we don't tight-loop repeatedly trying to do
|
|
|
|
|
* whatever it was that went wrong.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
/*
|
2013-08-17 20:06:27 +04:00
|
|
|
* Arrange to be called back from the top level to
|
|
|
|
|
* deal with the error condition on this socket.
|
2011-12-08 23:15:57 +04:00
|
|
|
*/
|
2013-08-17 20:06:27 +04:00
|
|
|
queue_toplevel_callback(socket_error_callback, s);
|
2002-10-31 22:49:52 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if (s->sending_oob) {
|
|
|
|
|
if (nsent < len) {
|
|
|
|
|
memmove(s->oobdata, s->oobdata+nsent, len-nsent);
|
|
|
|
|
s->sending_oob = len - nsent;
|
|
|
|
|
} else {
|
|
|
|
|
s->sending_oob = 0;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
bufchain_consume(&s->output_data, nsent);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-09-13 15:44:03 +04:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we reach here, we've finished sending everything we might
|
|
|
|
|
* have needed to send. Send EOF, if we need to.
|
|
|
|
|
*/
|
|
|
|
|
if (s->outgoingeof == EOF_PENDING) {
|
|
|
|
|
shutdown(s->s, SHUT_WR);
|
|
|
|
|
s->outgoingeof = EOF_SENT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Also update the select status, because we don't need to select
|
|
|
|
|
* for writing any more.
|
|
|
|
|
*/
|
2003-03-29 19:47:06 +03:00
|
|
|
uxsel_tell(s);
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2019-02-06 23:42:44 +03:00
|
|
|
static size_t sk_net_write(Socket *sock, const void *buf, size_t len)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2011-09-13 15:44:03 +04:00
|
|
|
assert(s->outgoingeof == EOF_NO);
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
/*
|
|
|
|
|
* Add the data to the buffer list on the socket.
|
|
|
|
|
*/
|
|
|
|
|
bufchain_add(&s->output_data, buf, len);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now try sending from the start of the buffer list.
|
|
|
|
|
*/
|
|
|
|
|
if (s->writable)
|
|
|
|
|
try_send(s);
|
|
|
|
|
|
2003-04-18 13:00:37 +04:00
|
|
|
/*
|
|
|
|
|
* Update the select() status to correctly reflect whether or
|
|
|
|
|
* not we should be selecting for write.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
return bufchain_size(&s->output_data);
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-06 23:42:44 +03:00
|
|
|
static size_t sk_net_write_oob(Socket *sock, const void *buf, size_t len)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2011-09-13 15:44:03 +04:00
|
|
|
assert(s->outgoingeof == EOF_NO);
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
/*
|
|
|
|
|
* Replace the buffer list on the socket with the data.
|
|
|
|
|
*/
|
|
|
|
|
bufchain_clear(&s->output_data);
|
|
|
|
|
assert(len <= sizeof(s->oobdata));
|
|
|
|
|
memcpy(s->oobdata, buf, len);
|
|
|
|
|
s->sending_oob = len;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now try sending from the start of the buffer list.
|
|
|
|
|
*/
|
|
|
|
|
if (s->writable)
|
|
|
|
|
try_send(s);
|
|
|
|
|
|
2003-04-18 13:00:37 +04:00
|
|
|
/*
|
|
|
|
|
* Update the select() status to correctly reflect whether or
|
|
|
|
|
* not we should be selecting for write.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
|
2002-10-31 22:49:52 +03:00
|
|
|
return s->sending_oob;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
static void sk_net_write_eof(Socket *sock)
|
2011-09-13 15:44:03 +04:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2011-09-13 15:44:03 +04:00
|
|
|
|
|
|
|
|
assert(s->outgoingeof == EOF_NO);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Mark the socket as pending outgoing EOF.
|
|
|
|
|
*/
|
|
|
|
|
s->outgoingeof = EOF_PENDING;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now try sending from the start of the buffer list.
|
|
|
|
|
*/
|
|
|
|
|
if (s->writable)
|
|
|
|
|
try_send(s);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Update the select() status to correctly reflect whether or
|
|
|
|
|
* not we should be selecting for write.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-31 00:52:30 +03:00
|
|
|
static void net_select_result(int fd, int event)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
char buf[20480]; /* nice big buffer for plenty of speed */
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *s;
|
2018-11-03 20:04:14 +03:00
|
|
|
bool atmark = true;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
/* Find the Socket structure */
|
2003-05-10 12:35:54 +04:00
|
|
|
s = find234(sktree, &fd, cmpforsearch);
|
2002-10-31 22:49:52 +03:00
|
|
|
if (!s)
|
2016-05-31 00:52:30 +03:00
|
|
|
return; /* boggle */
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2019-01-22 21:25:54 +03:00
|
|
|
noise_ultralight(NOISE_SOURCE_IOID, fd);
|
2002-10-31 22:49:52 +03:00
|
|
|
|
|
|
|
|
switch (event) {
|
|
|
|
|
case 4: /* exceptional */
|
|
|
|
|
if (!s->oobinline) {
|
|
|
|
|
/*
|
|
|
|
|
* On a non-oobinline socket, this indicates that we
|
|
|
|
|
* can immediately perform an OOB read and get back OOB
|
|
|
|
|
* data, which we will send to the back end with
|
|
|
|
|
* type==2 (urgent data).
|
|
|
|
|
*/
|
|
|
|
|
ret = recv(s->s, buf, sizeof(buf), MSG_OOB);
|
2019-01-22 21:25:54 +03:00
|
|
|
noise_ultralight(NOISE_SOURCE_IOLEN, ret);
|
2002-10-31 22:49:52 +03:00
|
|
|
if (ret <= 0) {
|
2016-05-31 00:52:30 +03:00
|
|
|
plug_closing(s->plug,
|
|
|
|
|
ret == 0 ? "Internal networking trouble" :
|
|
|
|
|
strerror(errno), errno, 0);
|
2002-10-31 22:49:52 +03:00
|
|
|
} else {
|
2005-01-16 17:29:34 +03:00
|
|
|
/*
|
|
|
|
|
* Receiving actual data on a socket means we can
|
|
|
|
|
* stop falling back through the candidate
|
|
|
|
|
* addresses to connect to.
|
|
|
|
|
*/
|
|
|
|
|
if (s->addr) {
|
|
|
|
|
sk_addr_free(s->addr);
|
|
|
|
|
s->addr = NULL;
|
|
|
|
|
}
|
2016-05-31 00:52:30 +03:00
|
|
|
plug_receive(s->plug, 2, buf, ret);
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we reach here, this is an oobinline socket, which
|
2002-11-01 16:36:48 +03:00
|
|
|
* means we should set s->oobpending and then deal with it
|
|
|
|
|
* when we get called for the readability event (which
|
|
|
|
|
* should also occur).
|
2002-10-31 22:49:52 +03:00
|
|
|
*/
|
2018-10-29 22:50:29 +03:00
|
|
|
s->oobpending = true;
|
2002-11-01 16:36:48 +03:00
|
|
|
break;
|
2002-10-31 22:49:52 +03:00
|
|
|
case 1: /* readable; also acceptance */
|
|
|
|
|
if (s->listener) {
|
|
|
|
|
/*
|
|
|
|
|
* On a listening socket, the readability event means a
|
|
|
|
|
* connection is ready to be accepted.
|
|
|
|
|
*/
|
2009-08-07 02:55:15 +04:00
|
|
|
union sockaddr_union su;
|
|
|
|
|
socklen_t addrlen = sizeof(su);
|
2013-11-17 18:03:55 +04:00
|
|
|
accept_ctx_t actx;
|
2002-10-31 22:49:52 +03:00
|
|
|
int t; /* socket of connection */
|
|
|
|
|
|
2009-08-07 02:55:15 +04:00
|
|
|
memset(&su, 0, addrlen);
|
|
|
|
|
t = accept(s->s, &su.sa, &addrlen);
|
2002-10-31 22:49:52 +03:00
|
|
|
if (t < 0) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-19 22:10:02 +04:00
|
|
|
nonblock(t);
|
2013-11-17 18:03:55 +04:00
|
|
|
actx.i = t;
|
2008-02-21 12:18:24 +03:00
|
|
|
|
2013-11-17 18:04:29 +04:00
|
|
|
if ((!s->addr || s->addr->superfamily != UNIX) &&
|
|
|
|
|
s->localhost_only && !sockaddr_is_loopback(&su.sa)) {
|
2002-10-31 22:49:52 +03:00
|
|
|
close(t); /* someone let nonlocal through?! */
|
2018-05-27 11:29:33 +03:00
|
|
|
} else if (plug_accepting(s->plug, sk_net_accept, actx)) {
|
2002-10-31 22:49:52 +03:00
|
|
|
close(t); /* denied or error */
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we reach here, this is not a listening socket, so
|
|
|
|
|
* readability really means readability.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* In the case the socket is still frozen, we don't even bother */
|
2013-07-21 11:40:36 +04:00
|
|
|
if (s->frozen)
|
2002-10-31 22:49:52 +03:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We have received data on the socket. For an oobinline
|
|
|
|
|
* socket, this might be data _before_ an urgent pointer,
|
|
|
|
|
* in which case we send it to the back end with type==1
|
|
|
|
|
* (data prior to urgent).
|
|
|
|
|
*/
|
|
|
|
|
if (s->oobinline && s->oobpending) {
|
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 22:23:19 +03:00
|
|
|
int atmark_from_ioctl;
|
|
|
|
|
if (ioctl(s->s, SIOCATMARK, &atmark_from_ioctl) == 0) {
|
|
|
|
|
atmark = atmark_from_ioctl;
|
|
|
|
|
if (atmark)
|
|
|
|
|
s->oobpending = false; /* clear this indicator */
|
|
|
|
|
}
|
2002-10-31 22:49:52 +03:00
|
|
|
} else
|
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 22:23:19 +03:00
|
|
|
atmark = true;
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2002-11-01 16:36:48 +03:00
|
|
|
ret = recv(s->s, buf, s->oobpending ? 1 : sizeof(buf), 0);
|
2019-01-22 21:25:54 +03:00
|
|
|
noise_ultralight(NOISE_SOURCE_IOLEN, ret);
|
2002-10-31 22:49:52 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
|
if (errno == EWOULDBLOCK) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (ret < 0) {
|
2016-05-31 00:52:30 +03:00
|
|
|
plug_closing(s->plug, strerror(errno), errno, 0);
|
2002-10-31 22:49:52 +03:00
|
|
|
} else if (0 == ret) {
|
2018-10-29 22:50:29 +03:00
|
|
|
s->incomingeof = true; /* stop trying to read now */
|
2011-09-13 15:44:03 +04:00
|
|
|
uxsel_tell(s);
|
2016-05-31 00:52:30 +03:00
|
|
|
plug_closing(s->plug, NULL, 0, 0);
|
2002-10-31 22:49:52 +03:00
|
|
|
} else {
|
2005-01-16 17:29:34 +03:00
|
|
|
/*
|
|
|
|
|
* Receiving actual data on a socket means we can
|
|
|
|
|
* stop falling back through the candidate
|
|
|
|
|
* addresses to connect to.
|
|
|
|
|
*/
|
|
|
|
|
if (s->addr) {
|
|
|
|
|
sk_addr_free(s->addr);
|
|
|
|
|
s->addr = NULL;
|
|
|
|
|
}
|
2016-05-31 00:52:30 +03:00
|
|
|
plug_receive(s->plug, atmark ? 0 : 1, buf, ret);
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case 2: /* writable */
|
2003-01-09 21:14:24 +03:00
|
|
|
if (!s->connected) {
|
|
|
|
|
/*
|
|
|
|
|
* select() reports a socket as _writable_ when an
|
2017-01-25 01:30:44 +03:00
|
|
|
* asynchronous connect() attempt either completes or
|
|
|
|
|
* fails. So first we must find out which.
|
2003-01-09 21:14:24 +03:00
|
|
|
*/
|
2017-01-25 01:30:44 +03:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
socklen_t errlen = sizeof(err);
|
|
|
|
|
char *errmsg = NULL;
|
|
|
|
|
if (getsockopt(s->s, SOL_SOCKET, SO_ERROR, &err, &errlen)<0) {
|
|
|
|
|
errmsg = dupprintf("getsockopt(SO_ERROR): %s",
|
|
|
|
|
strerror(errno));
|
|
|
|
|
err = errno; /* got to put something in here */
|
|
|
|
|
} else if (err != 0) {
|
|
|
|
|
errmsg = dupstr(strerror(err));
|
|
|
|
|
}
|
|
|
|
|
if (errmsg) {
|
|
|
|
|
/*
|
|
|
|
|
* The asynchronous connection attempt failed.
|
|
|
|
|
* Report the problem via plug_log, and try again
|
|
|
|
|
* with the next candidate address, if we have
|
|
|
|
|
* more than one.
|
|
|
|
|
*/
|
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 21:10:23 +03:00
|
|
|
SockAddr thisaddr;
|
2017-01-25 01:30:44 +03:00
|
|
|
assert(s->addr);
|
2017-01-28 13:56:19 +03:00
|
|
|
|
|
|
|
|
thisaddr = sk_extractaddr_tmp(s->addr, &s->step);
|
|
|
|
|
plug_log(s->plug, 1, &thisaddr, s->port, errmsg, err);
|
|
|
|
|
|
2017-01-25 01:30:44 +03:00
|
|
|
while (err && s->addr && sk_nextaddr(s->addr, &s->step)) {
|
|
|
|
|
err = try_connect(s);
|
|
|
|
|
}
|
2017-11-26 22:59:27 +03:00
|
|
|
if (err) {
|
2016-05-31 00:52:30 +03:00
|
|
|
plug_closing(s->plug, strerror(err), err, 0);
|
2017-11-26 22:59:27 +03:00
|
|
|
return; /* socket is now presumably defunct */
|
|
|
|
|
}
|
2017-01-25 01:30:44 +03:00
|
|
|
if (!s->connected)
|
2016-05-31 00:52:30 +03:00
|
|
|
return; /* another async attempt in progress */
|
2017-01-25 01:30:44 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we get here, we've managed to make a connection.
|
|
|
|
|
*/
|
|
|
|
|
if (s->addr) {
|
|
|
|
|
sk_addr_free(s->addr);
|
|
|
|
|
s->addr = NULL;
|
|
|
|
|
}
|
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 22:23:19 +03:00
|
|
|
s->connected = true;
|
|
|
|
|
s->writable = true;
|
2003-03-29 19:47:06 +03:00
|
|
|
uxsel_tell(s);
|
2003-01-09 21:14:24 +03:00
|
|
|
} else {
|
2019-02-06 23:42:44 +03:00
|
|
|
size_t bufsize_before, bufsize_after;
|
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 22:23:19 +03:00
|
|
|
s->writable = true;
|
2002-10-31 22:49:52 +03:00
|
|
|
bufsize_before = s->sending_oob + bufchain_size(&s->output_data);
|
|
|
|
|
try_send(s);
|
|
|
|
|
bufsize_after = s->sending_oob + bufchain_size(&s->output_data);
|
|
|
|
|
if (bufsize_after < bufsize_before)
|
|
|
|
|
plug_sent(s->plug, bufsize_after);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Special error values are returned from sk_namelookup and sk_new
|
|
|
|
|
* if there's a problem. These functions extract an error message,
|
|
|
|
|
* or return NULL if there's no problem.
|
|
|
|
|
*/
|
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 21:10:23 +03:00
|
|
|
const char *sk_addr_error(SockAddr *addr)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
|
|
|
|
return addr->error;
|
|
|
|
|
}
|
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 21:10:23 +03:00
|
|
|
static const char *sk_net_socket_error(Socket *sock)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 22:49:52 +03:00
|
|
|
return s->error;
|
|
|
|
|
}
|
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
static void sk_net_set_frozen(Socket *sock, bool is_frozen)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 22:49:52 +03:00
|
|
|
if (s->frozen == is_frozen)
|
|
|
|
|
return;
|
|
|
|
|
s->frozen = is_frozen;
|
2003-03-29 19:47:06 +03:00
|
|
|
uxsel_tell(s);
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
2018-10-18 22:06:42 +03:00
|
|
|
static SocketPeerInfo *sk_net_peer_info(Socket *sock)
|
2015-05-18 15:57:45 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2016-01-29 00:22:07 +03:00
|
|
|
union sockaddr_union addr;
|
2015-05-18 15:57:45 +03:00
|
|
|
socklen_t addrlen = sizeof(addr);
|
2016-01-29 00:22:07 +03:00
|
|
|
#ifndef NO_IPV6
|
2015-05-18 15:57:45 +03:00
|
|
|
char buf[INET6_ADDRSTRLEN];
|
2016-01-29 00:22:07 +03:00
|
|
|
#endif
|
2018-10-18 22:06:42 +03:00
|
|
|
SocketPeerInfo *pi;
|
2015-05-18 15:57:45 +03:00
|
|
|
|
2016-01-29 00:22:07 +03:00
|
|
|
if (getpeername(s->s, &addr.sa, &addrlen) < 0)
|
2015-05-18 15:57:45 +03:00
|
|
|
return NULL;
|
2018-10-18 22:06:42 +03:00
|
|
|
|
|
|
|
|
pi = snew(SocketPeerInfo);
|
|
|
|
|
pi->addressfamily = ADDRTYPE_UNSPEC;
|
|
|
|
|
pi->addr_text = NULL;
|
|
|
|
|
pi->port = -1;
|
|
|
|
|
pi->log_text = NULL;
|
|
|
|
|
|
2016-01-29 00:22:07 +03:00
|
|
|
if (addr.storage.ss_family == AF_INET) {
|
2018-10-18 22:06:42 +03:00
|
|
|
pi->addressfamily = ADDRTYPE_IPV4;
|
|
|
|
|
memcpy(pi->addr_bin.ipv4, &addr.sin.sin_addr, 4);
|
|
|
|
|
pi->port = ntohs(addr.sin.sin_port);
|
|
|
|
|
pi->addr_text = dupstr(inet_ntoa(addr.sin.sin_addr));
|
|
|
|
|
pi->log_text = dupprintf("%s:%d", pi->addr_text, pi->port);
|
|
|
|
|
|
2015-05-18 15:57:45 +03:00
|
|
|
#ifndef NO_IPV6
|
2016-01-29 00:22:07 +03:00
|
|
|
} else if (addr.storage.ss_family == AF_INET6) {
|
2018-10-18 22:06:42 +03:00
|
|
|
pi->addressfamily = ADDRTYPE_IPV6;
|
|
|
|
|
memcpy(pi->addr_bin.ipv6, &addr.sin6.sin6_addr, 16);
|
|
|
|
|
pi->port = ntohs(addr.sin6.sin6_port);
|
|
|
|
|
pi->addr_text = dupstr(
|
|
|
|
|
inet_ntop(AF_INET6, &addr.sin6.sin6_addr, buf, sizeof(buf)));
|
|
|
|
|
pi->log_text = dupprintf("[%s]:%d", pi->addr_text, pi->port);
|
2015-05-18 15:57:45 +03:00
|
|
|
#endif
|
2018-10-18 22:06:42 +03:00
|
|
|
|
2016-01-29 00:22:07 +03:00
|
|
|
} else if (addr.storage.ss_family == AF_UNIX) {
|
2018-10-18 22:06:42 +03:00
|
|
|
pi->addressfamily = ADDRTYPE_LOCAL;
|
|
|
|
|
|
2015-05-18 15:57:45 +03:00
|
|
|
/*
|
|
|
|
|
* For Unix sockets, the source address is unlikely to be
|
2018-10-18 22:06:42 +03:00
|
|
|
* helpful, so we leave addr_txt NULL (and we certainly can't
|
|
|
|
|
* fill in port, obviously). Instead, we try SO_PEERCRED and
|
|
|
|
|
* try to get the source pid, and put that in the log text.
|
2015-05-18 15:57:45 +03:00
|
|
|
*/
|
|
|
|
|
int pid, uid, gid;
|
|
|
|
|
if (so_peercred(s->s, &pid, &uid, &gid)) {
|
|
|
|
|
char uidbuf[64], gidbuf[64];
|
|
|
|
|
sprintf(uidbuf, "%d", uid);
|
|
|
|
|
sprintf(gidbuf, "%d", gid);
|
|
|
|
|
struct passwd *pw = getpwuid(uid);
|
|
|
|
|
struct group *gr = getgrgid(gid);
|
2018-10-18 22:06:42 +03:00
|
|
|
pi->log_text = dupprintf("pid %d (%s:%s)", pid,
|
|
|
|
|
pw ? pw->pw_name : uidbuf,
|
|
|
|
|
gr ? gr->gr_name : gidbuf);
|
2015-05-18 15:57:45 +03:00
|
|
|
}
|
|
|
|
|
} else {
|
2018-10-18 22:06:42 +03:00
|
|
|
sfree(pi);
|
2015-05-18 15:57:45 +03:00
|
|
|
return NULL;
|
|
|
|
|
}
|
2018-10-18 22:06:42 +03:00
|
|
|
|
|
|
|
|
return pi;
|
2015-05-18 15:57:45 +03:00
|
|
|
}
|
|
|
|
|
|
2018-05-27 11:29:33 +03:00
|
|
|
static void uxsel_tell(NetSocket *s)
|
2002-10-31 22:49:52 +03:00
|
|
|
{
|
2003-03-29 19:47:06 +03:00
|
|
|
int rwx = 0;
|
2011-12-08 23:15:57 +04:00
|
|
|
if (!s->pending_error) {
|
|
|
|
|
if (s->listener) {
|
|
|
|
|
rwx |= 1; /* read == accept */
|
|
|
|
|
} else {
|
|
|
|
|
if (!s->connected)
|
|
|
|
|
rwx |= 2; /* write == connect */
|
|
|
|
|
if (s->connected && !s->frozen && !s->incomingeof)
|
|
|
|
|
rwx |= 1 | 4; /* read, except */
|
|
|
|
|
if (bufchain_size(&s->output_data))
|
|
|
|
|
rwx |= 2; /* write */
|
|
|
|
|
}
|
2005-02-16 14:44:44 +03:00
|
|
|
}
|
2003-03-29 19:47:06 +03:00
|
|
|
uxsel_set(s->s, rwx, net_select_result);
|
2002-10-31 22:49:52 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int net_service_lookup(char *service)
|
|
|
|
|
{
|
|
|
|
|
struct servent *se;
|
|
|
|
|
se = getservbyname(service, NULL);
|
|
|
|
|
if (se != NULL)
|
|
|
|
|
return ntohs(se->s_port);
|
|
|
|
|
else
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2004-05-31 18:01:52 +04:00
|
|
|
|
Since r8305, Unix PuTTY has always "upgraded" an X11 display like "localhost:0"
to a Unix-domain socket. This typically works fine when PuTTY is run on the
same machine as the X server, but it's broken multi-hop X forwarding through
OpenSSH; when OpenSSH creates a proxy X server "localhost:10", it only listens
on TCP, not on a Unix-domain socket.
Instead, when deciding on the details of the display, we actively probe to see
if there's a Unix-domain socket we can use instead, and only use it if it's
there, falling back to the specified IP "localhost" if not.
Independently, when looking for local auth details in Xauthority for a
"localhost" TCP display, we prefer a matching Unix-domain entry, but will fall
back to an IP "localhost" entry (which would be unusual, but we don't trust a
Windows X server not to do it) -- this is a generalisation of the special case
added in r2538 (but removed in r8305, as the automatic upgrade masked the need
for it).
(This is now done in platform-independent code, so a side-effect is that
get_hostname() is now part of the networking abstraction on all platforms.)
[originally from svn r8462]
[r2538 == fda998324345ba50a913655754303ce8f0a4cfde]
[r8305 == ca6fc3a4daf51166a15693feffc967bee9e3f59a]
2009-02-24 04:01:23 +03:00
|
|
|
char *get_hostname(void)
|
|
|
|
|
{
|
|
|
|
|
int len = 128;
|
|
|
|
|
char *hostname = NULL;
|
|
|
|
|
do {
|
|
|
|
|
len *= 2;
|
|
|
|
|
hostname = sresize(hostname, len, char);
|
|
|
|
|
if ((gethostname(hostname, len) < 0) &&
|
|
|
|
|
(errno != ENAMETOOLONG)) {
|
|
|
|
|
sfree(hostname);
|
|
|
|
|
hostname = NULL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
} while (strlen(hostname) >= len-1);
|
|
|
|
|
return hostname;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
SockAddr *platform_get_x11_unix_address(const char *sockpath, int displaynum)
|
2004-05-31 18:01:52 +04: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 21:10:23 +03:00
|
|
|
SockAddr *ret = snew(SockAddr);
|
2004-05-31 18:01:52 +04:00
|
|
|
int n;
|
|
|
|
|
|
|
|
|
|
memset(ret, 0, sizeof *ret);
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->superfamily = UNIX;
|
2008-05-28 23:23:57 +04:00
|
|
|
/*
|
2008-11-17 21:38:09 +03:00
|
|
|
* In special circumstances (notably Mac OS X Leopard), we'll
|
|
|
|
|
* have been passed an explicit Unix socket path.
|
2008-05-28 23:23:57 +04:00
|
|
|
*/
|
2008-11-17 21:38:09 +03:00
|
|
|
if (sockpath) {
|
2008-05-28 23:23:57 +04:00
|
|
|
n = snprintf(ret->hostname, sizeof ret->hostname,
|
2008-11-17 21:38:09 +03:00
|
|
|
"%s", sockpath);
|
2008-05-28 23:23:57 +04:00
|
|
|
} else {
|
|
|
|
|
n = snprintf(ret->hostname, sizeof ret->hostname,
|
|
|
|
|
"%s%d", X11_UNIX_PATH, displaynum);
|
|
|
|
|
}
|
2008-11-17 21:38:09 +03:00
|
|
|
|
|
|
|
|
if (n < 0)
|
2004-05-31 18:01:52 +04:00
|
|
|
ret->error = "snprintf failed";
|
2008-11-17 21:38:09 +03:00
|
|
|
else if (n >= sizeof ret->hostname)
|
2004-05-31 18:01:52 +04:00
|
|
|
ret->error = "X11 UNIX name too long";
|
2008-11-17 21:38:09 +03:00
|
|
|
|
2005-01-16 17:29:34 +03:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->ais = NULL;
|
2005-01-16 17:29:34 +03:00
|
|
|
#else
|
|
|
|
|
ret->addresses = NULL;
|
2008-11-08 19:45:45 +03:00
|
|
|
ret->naddresses = 0;
|
2005-01-16 17:29:34 +03:00
|
|
|
#endif
|
2008-11-08 19:58:55 +03:00
|
|
|
ret->refcount = 1;
|
2004-05-31 18:01:52 +04:00
|
|
|
return ret;
|
|
|
|
|
}
|
2013-11-17 18:04:29 +04: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 21:10:23 +03:00
|
|
|
SockAddr *unix_sock_addr(const char *path)
|
2013-11-17 18:04:29 +04: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 21:10:23 +03:00
|
|
|
SockAddr *ret = snew(SockAddr);
|
2013-11-17 18:04:29 +04:00
|
|
|
int n;
|
|
|
|
|
|
|
|
|
|
memset(ret, 0, sizeof *ret);
|
|
|
|
|
ret->superfamily = UNIX;
|
|
|
|
|
n = snprintf(ret->hostname, sizeof ret->hostname, "%s", path);
|
|
|
|
|
|
|
|
|
|
if (n < 0)
|
|
|
|
|
ret->error = "snprintf failed";
|
2017-02-15 00:59:52 +03:00
|
|
|
else if (n >= sizeof ret->hostname ||
|
|
|
|
|
n >= sizeof(((struct sockaddr_un *)0)->sun_path))
|
2013-11-17 18:04:29 +04:00
|
|
|
ret->error = "socket pathname too long";
|
|
|
|
|
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
ret->ais = NULL;
|
|
|
|
|
#else
|
|
|
|
|
ret->addresses = NULL;
|
|
|
|
|
ret->naddresses = 0;
|
|
|
|
|
#endif
|
|
|
|
|
ret->refcount = 1;
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:23 +03:00
|
|
|
Socket *new_unix_listener(SockAddr *listenaddr, Plug *plug)
|
2013-11-17 18:04:29 +04:00
|
|
|
{
|
|
|
|
|
int s;
|
|
|
|
|
union sockaddr_union u;
|
|
|
|
|
union sockaddr_union *addr;
|
|
|
|
|
int addrlen;
|
2018-05-27 11:29:33 +03:00
|
|
|
NetSocket *ret;
|
2013-11-17 18:04:29 +04:00
|
|
|
int retcode;
|
|
|
|
|
|
|
|
|
|
/*
|
2018-05-27 11:29:33 +03:00
|
|
|
* Create NetSocket structure.
|
2013-11-17 18:04:29 +04:00
|
|
|
*/
|
2018-05-27 11:29:33 +03:00
|
|
|
ret = snew(NetSocket);
|
2018-10-05 09:24:16 +03:00
|
|
|
ret->sock.vt = &NetSocket_sockvt;
|
2013-11-17 18:04:29 +04:00
|
|
|
ret->error = NULL;
|
|
|
|
|
ret->plug = plug;
|
|
|
|
|
bufchain_init(&ret->output_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 22:23:19 +03:00
|
|
|
ret->writable = false; /* to start with */
|
2013-11-17 18:04:29 +04:00
|
|
|
ret->sending_oob = 0;
|
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 22:23:19 +03:00
|
|
|
ret->frozen = false;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->localhost_only = true;
|
2013-11-17 18:04:29 +04:00
|
|
|
ret->pending_error = 0;
|
|
|
|
|
ret->parent = ret->child = NULL;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->oobpending = false;
|
2013-11-17 18:04:29 +04:00
|
|
|
ret->outgoingeof = EOF_NO;
|
2018-10-29 22:50:29 +03:00
|
|
|
ret->incomingeof = false;
|
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 22:23:19 +03:00
|
|
|
ret->listener = true;
|
2013-11-17 18:04:29 +04:00
|
|
|
ret->addr = listenaddr;
|
2013-11-17 18:04:33 +04:00
|
|
|
ret->s = -1;
|
2013-11-17 18:04:29 +04:00
|
|
|
|
|
|
|
|
assert(listenaddr->superfamily == UNIX);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Open socket.
|
|
|
|
|
*/
|
|
|
|
|
s = socket(AF_UNIX, SOCK_STREAM, 0);
|
|
|
|
|
if (s < 0) {
|
|
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2013-11-17 18:04:29 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cloexec(s);
|
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
ret->oobinline = false;
|
2013-11-17 18:04:29 +04:00
|
|
|
|
|
|
|
|
memset(&u, '\0', sizeof(u));
|
|
|
|
|
u.su.sun_family = AF_UNIX;
|
2018-09-26 16:20:25 +03:00
|
|
|
#if __GNUC__ >= 8
|
|
|
|
|
# pragma GCC diagnostic push
|
|
|
|
|
# pragma GCC diagnostic ignored "-Wstringop-truncation"
|
|
|
|
|
#endif // __GNUC__ >= 8
|
2013-11-17 18:04:29 +04:00
|
|
|
strncpy(u.su.sun_path, listenaddr->hostname, sizeof(u.su.sun_path)-1);
|
2018-09-26 16:20:25 +03:00
|
|
|
#if __GNUC__ >= 8
|
|
|
|
|
# pragma GCC diagnostic pop
|
|
|
|
|
#endif // __GNUC__ >= 8
|
2013-11-17 18:04:29 +04:00
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.su);
|
|
|
|
|
|
|
|
|
|
if (unlink(u.su.sun_path) < 0 && errno != ENOENT) {
|
|
|
|
|
close(s);
|
|
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2013-11-17 18:04:29 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
retcode = bind(s, &addr->sa, addrlen);
|
|
|
|
|
if (retcode < 0) {
|
|
|
|
|
close(s);
|
|
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2013-11-17 18:04:29 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (listen(s, SOMAXCONN) < 0) {
|
|
|
|
|
close(s);
|
|
|
|
|
ret->error = strerror(errno);
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2013-11-17 18:04:29 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret->s = s;
|
|
|
|
|
|
|
|
|
|
uxsel_tell(ret);
|
|
|
|
|
add234(sktree, ret);
|
|
|
|
|
|
2018-10-05 09:24:16 +03:00
|
|
|
return &ret->sock;
|
2013-11-17 18:04:29 +04:00
|
|
|
}
|
