2002-10-31 19:49:52 +00: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 14:01:52 +00:00
|
|
|
#include <sys/un.h>
|
2015-05-18 12:57:45 +00:00
|
|
|
#include <pwd.h>
|
|
|
|
|
#include <grp.h>
|
2002-10-31 19:49:52 +00:00
|
|
|
|
|
|
|
|
#include "putty.h"
|
|
|
|
|
#include "network.h"
|
|
|
|
|
#include "tree234.h"
|
|
|
|
|
|
2005-04-25 18:51:15 +00:00
|
|
|
/* Solaris needs <sys/sockio.h> for SIOCATMARK. */
|
2005-05-05 22:47:30 +00:00
|
|
|
#ifndef SIOCATMARK
|
2005-04-25 18:51:15 +00:00
|
|
|
#include <sys/sockio.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2004-05-31 14:01:52 +00:00
|
|
|
#ifndef X11_UNIX_PATH
|
|
|
|
|
# define X11_UNIX_PATH "/tmp/.X11-unix/X"
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
2009-08-06 22:12:05 +00: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-28 21:22:07 +00:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
struct sockaddr_in6 sin6;
|
|
|
|
|
#endif
|
2009-08-06 22:55:15 +00:00
|
|
|
struct sockaddr_un su;
|
2009-08-06 22:12:05 +00:00
|
|
|
};
|
|
|
|
|
|
2008-11-08 16:45:45 +00: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
|
2019-09-08 19:29:00 +00:00
|
|
|
struct addrinfo *ai; /* steps along addr->ais */
|
2008-11-08 16:45:45 +00:00
|
|
|
#endif
|
|
|
|
|
int curraddr;
|
|
|
|
|
};
|
|
|
|
|
|
2018-05-27 08:29:33 +00:00
|
|
|
typedef struct NetSocket NetSocket;
|
|
|
|
|
struct NetSocket {
|
2003-05-04 14:18:18 +00:00
|
|
|
const char *error;
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
Plug *plug;
|
2002-10-31 19:49:52 +00: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 19:23:19 +00: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 19:49:52 +00:00
|
|
|
char oobdata[1];
|
2019-02-06 20:42:44 +00: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 19:23:19 +00:00
|
|
|
bool oobpending; /* is there OOB data available to read? */
|
|
|
|
|
bool oobinline;
|
2011-09-13 11:44:03 +00: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 19:23:19 +00:00
|
|
|
bool incomingeof;
|
2019-09-08 19:29:00 +00: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 19:23:19 +00: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 18:10:23 +00:00
|
|
|
SockAddr *addr;
|
2008-11-08 16:45:45 +00:00
|
|
|
SockAddrStep step;
|
2008-08-20 22:21:04 +00: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 08:29:33 +00:00
|
|
|
NetSocket *parent, *child;
|
|
|
|
|
|
2018-10-05 06:24:16 +00:00
|
|
|
Socket sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
};
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
struct SockAddr {
|
2008-11-08 16:58:55 +00:00
|
|
|
int refcount;
|
2003-05-04 14:18:18 +00:00
|
|
|
const char *error;
|
2008-11-08 16:45:45 +00:00
|
|
|
enum { UNRESOLVED, UNIX, IP } superfamily;
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2019-09-08 19:29:00 +00:00
|
|
|
struct addrinfo *ais; /* Addresses IPv6 style. */
|
2003-04-16 23:33:44 +00:00
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
unsigned long *addresses; /* Addresses IPv4 style. */
|
2008-11-08 16:45:45 +00:00
|
|
|
int naddresses;
|
2002-10-31 19:49:52 +00:00
|
|
|
#endif
|
2019-09-08 19:29:00 +00:00
|
|
|
char hostname[512]; /* Store an unresolved host name. */
|
2002-10-31 19:49:52 +00:00
|
|
|
};
|
|
|
|
|
|
2008-11-08 16:45:45 +00: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-05 21:51:25 +00:00
|
|
|
/* Here we gratuitously reference 'step' to avoid gcc warnings about
|
|
|
|
|
* 'set but not used' when compiling -DNO_IPV6 */
|
2008-11-08 16:45:45 +00:00
|
|
|
#define SOCKADDR_FAMILY(addr, step) \
|
|
|
|
|
((addr)->superfamily == UNRESOLVED ? AF_UNSPEC : \
|
2014-02-05 21:51:25 +00:00
|
|
|
(addr)->superfamily == UNIX ? AF_UNIX : \
|
|
|
|
|
(step).curraddr ? AF_INET : AF_INET)
|
2008-11-08 16:45:45 +00: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 19:49:52 +00:00
|
|
|
static tree234 *sktree;
|
|
|
|
|
|
2018-05-27 08:29:33 +00:00
|
|
|
static void uxsel_tell(NetSocket *s);
|
2003-03-29 16:47:06 +00:00
|
|
|
|
2002-10-31 19:49:52 +00:00
|
|
|
static int cmpfortree(void *av, void *bv)
|
|
|
|
|
{
|
2018-05-27 08:29:33 +00:00
|
|
|
NetSocket *a = (NetSocket *) av, *b = (NetSocket *) bv;
|
2002-10-31 19:49:52 +00:00
|
|
|
int as = a->s, bs = b->s;
|
|
|
|
|
if (as < bs)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2002-10-31 19:49:52 +00:00
|
|
|
if (as > bs)
|
2019-09-08 19:29:00 +00:00
|
|
|
return +1;
|
2007-11-28 20:45:50 +00:00
|
|
|
if (a < b)
|
2022-08-03 19:48:46 +00:00
|
|
|
return -1;
|
2007-11-28 20:45:50 +00:00
|
|
|
if (a > b)
|
2022-08-03 19:48:46 +00:00
|
|
|
return +1;
|
2002-10-31 19:49:52 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int cmpforsearch(void *av, void *bv)
|
|
|
|
|
{
|
2018-05-27 08:29:33 +00:00
|
|
|
NetSocket *b = (NetSocket *) bv;
|
2003-05-10 08:35:54 +00:00
|
|
|
int as = *(int *)av, bs = b->s;
|
2002-10-31 19:49:52 +00:00
|
|
|
if (as < bs)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2002-10-31 19:49:52 +00:00
|
|
|
if (as > bs)
|
2019-09-08 19:29:00 +00:00
|
|
|
return +1;
|
2002-10-31 19:49:52 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void sk_init(void)
|
|
|
|
|
{
|
|
|
|
|
sktree = newtree234(cmpfortree);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void sk_cleanup(void)
|
|
|
|
|
{
|
2018-05-27 08:29:33 +00:00
|
|
|
NetSocket *s;
|
2002-10-31 19:49:52 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (sktree) {
|
2019-09-08 19:29:00 +00:00
|
|
|
for (i = 0; (s = index234(sktree, i)) != NULL; i++) {
|
|
|
|
|
close(s->s);
|
|
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-29 07:05:39 +00:00
|
|
|
SockAddr *sk_namelookup(const char *host, char **canonicalname,
|
|
|
|
|
int address_family)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2022-04-29 07:05:39 +00:00
|
|
|
*canonicalname = NULL;
|
|
|
|
|
|
2020-02-16 16:22:17 +00:00
|
|
|
if (host[0] == '/') {
|
|
|
|
|
*canonicalname = dupstr(host);
|
|
|
|
|
return unix_sock_addr(host);
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-29 07:05:39 +00:00
|
|
|
SockAddr *addr = snew(SockAddr);
|
|
|
|
|
memset(addr, 0, sizeof(SockAddr));
|
|
|
|
|
addr->superfamily = UNRESOLVED;
|
|
|
|
|
addr->refcount = 1;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2022-04-29 07:05:39 +00:00
|
|
|
/*
|
|
|
|
|
* Use getaddrinfo, as long as it's available. This should handle
|
|
|
|
|
* both IPv4 and IPv6 address literals, and hostnames, in one
|
|
|
|
|
* unified API.
|
|
|
|
|
*/
|
2014-01-25 15:58:54 +00:00
|
|
|
{
|
2022-04-29 07:05:39 +00:00
|
|
|
struct addrinfo hints;
|
|
|
|
|
memset(&hints, 0, sizeof(hints));
|
|
|
|
|
hints.ai_family = (address_family == ADDRTYPE_IPV4 ? AF_INET :
|
|
|
|
|
address_family == ADDRTYPE_IPV6 ? AF_INET6 :
|
|
|
|
|
AF_UNSPEC);
|
|
|
|
|
hints.ai_flags = AI_CANONNAME;
|
|
|
|
|
hints.ai_socktype = SOCK_STREAM;
|
|
|
|
|
|
|
|
|
|
/* strip [] on IPv6 address literals */
|
|
|
|
|
char *trimmed_host = host_strduptrim(host);
|
|
|
|
|
int err = getaddrinfo(trimmed_host, NULL, &hints, &addr->ais);
|
2014-01-25 15:58:54 +00:00
|
|
|
sfree(trimmed_host);
|
2022-04-29 07:05:39 +00:00
|
|
|
|
|
|
|
|
if (addr->ais) {
|
|
|
|
|
addr->superfamily = IP;
|
|
|
|
|
if (addr->ais->ai_canonname)
|
|
|
|
|
*canonicalname = dupstr(addr->ais->ai_canonname);
|
|
|
|
|
else
|
|
|
|
|
*canonicalname = dupstr(host);
|
|
|
|
|
} else {
|
|
|
|
|
addr->error = gai_strerror(err);
|
|
|
|
|
}
|
|
|
|
|
return addr;
|
2014-01-25 15:58:54 +00:00
|
|
|
}
|
2018-12-01 09:35:52 +00:00
|
|
|
|
2003-04-16 23:33:44 +00:00
|
|
|
#else
|
2022-04-29 07:05:39 +00:00
|
|
|
/*
|
|
|
|
|
* Failing that (if IPv6 support was not compiled in), try the
|
|
|
|
|
* old-fashioned approach, which is to start by manually checking
|
|
|
|
|
* for an IPv4 literal and then use gethostbyname.
|
|
|
|
|
*/
|
|
|
|
|
unsigned long a = inet_addr(host);
|
|
|
|
|
if (a != (unsigned long) INADDR_NONE) {
|
|
|
|
|
addr->addresses = snew(unsigned long);
|
|
|
|
|
addr->naddresses = 1;
|
|
|
|
|
addr->addresses[0] = ntohl(a);
|
|
|
|
|
addr->superfamily = IP;
|
|
|
|
|
*canonicalname = dupstr(host);
|
|
|
|
|
return addr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct hostent *h = gethostbyname(host);
|
|
|
|
|
if (h) {
|
|
|
|
|
addr->superfamily = IP;
|
|
|
|
|
|
|
|
|
|
size_t n;
|
2019-09-08 19:29:00 +00:00
|
|
|
for (n = 0; h->h_addr_list[n]; n++);
|
2022-04-29 07:05:39 +00:00
|
|
|
addr->addresses = snewn(n, unsigned long);
|
|
|
|
|
addr->naddresses = n;
|
|
|
|
|
for (n = 0; n < addr->naddresses; n++) {
|
|
|
|
|
uint32_t a;
|
2019-09-08 19:29:00 +00:00
|
|
|
memcpy(&a, h->h_addr_list[n], sizeof(a));
|
2022-04-29 07:05:39 +00:00
|
|
|
addr->addresses[n] = ntohl(a);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
2022-04-29 07:05:39 +00:00
|
|
|
|
|
|
|
|
*canonicalname = dupstr(h->h_name);
|
2002-10-31 19:49:52 +00:00
|
|
|
} else {
|
2022-04-29 07:05:39 +00:00
|
|
|
addr->error = hstrerror(h_errno);
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
2022-04-29 07:05:39 +00:00
|
|
|
return addr;
|
2003-04-16 23:33:44 +00:00
|
|
|
#endif
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
SockAddr *sk_nonamelookup(const char *host)
|
2002-12-18 16:23:11 +00:00
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
SockAddr *addr = snew(SockAddr);
|
|
|
|
|
addr->error = NULL;
|
|
|
|
|
addr->superfamily = UNRESOLVED;
|
|
|
|
|
strncpy(addr->hostname, host, lenof(addr->hostname));
|
|
|
|
|
addr->hostname[lenof(addr->hostname)-1] = '\0';
|
2005-01-04 17:39:35 +00:00
|
|
|
#ifndef NO_IPV6
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->ais = NULL;
|
2005-01-16 14:29:34 +00:00
|
|
|
#else
|
|
|
|
|
ret->addresses = NULL;
|
2005-01-04 17:39:35 +00:00
|
|
|
#endif
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->refcount = 1;
|
|
|
|
|
return addr;
|
2002-12-18 16:23:11 +00:00
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool sk_nextaddr(SockAddr *addr, SockAddrStep *step)
|
2005-01-16 14:29:34 +00:00
|
|
|
{
|
|
|
|
|
#ifndef NO_IPV6
|
2008-11-08 16:45:45 +00:00
|
|
|
if (step->ai && step->ai->ai_next) {
|
2019-09-08 19:29:00 +00:00
|
|
|
step->ai = step->ai->ai_next;
|
|
|
|
|
return true;
|
2005-01-16 14:29:34 +00:00
|
|
|
} else
|
2019-09-08 19:29:00 +00:00
|
|
|
return false;
|
2005-01-16 14:29:34 +00:00
|
|
|
#else
|
2008-11-08 16:45:45 +00:00
|
|
|
if (step->curraddr+1 < addr->naddresses) {
|
2019-09-08 19:29:00 +00:00
|
|
|
step->curraddr++;
|
|
|
|
|
return true;
|
2005-01-16 14:29:34 +00:00
|
|
|
} else {
|
2019-09-08 19:29:00 +00:00
|
|
|
return false;
|
2005-01-16 14:29:34 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
#endif
|
2005-01-16 14:29:34 +00:00
|
|
|
}
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
void sk_getaddr(SockAddr *addr, char *buf, int buflen)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2013-11-17 14:04:29 +00:00
|
|
|
if (addr->superfamily == UNRESOLVED || addr->superfamily == UNIX) {
|
2019-09-08 19:29:00 +00:00
|
|
|
strncpy(buf, addr->hostname, buflen);
|
|
|
|
|
buf[buflen-1] = '\0';
|
2003-04-16 23:33:44 +00:00
|
|
|
} else {
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2019-09-08 19:29:00 +00:00
|
|
|
if (getnameinfo(addr->ais->ai_addr, addr->ais->ai_addrlen, buf, buflen,
|
|
|
|
|
NULL, 0, NI_NUMERICHOST) != 0) {
|
|
|
|
|
buf[0] = '\0';
|
|
|
|
|
strncat(buf, "<unknown>", buflen - 1);
|
|
|
|
|
}
|
2003-04-16 23:33:44 +00:00
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
struct in_addr a;
|
|
|
|
|
SockAddrStep step;
|
|
|
|
|
START_STEP(addr, step);
|
|
|
|
|
assert(SOCKADDR_FAMILY(addr, step) == AF_INET);
|
|
|
|
|
a.s_addr = htonl(addr->addresses[0]);
|
|
|
|
|
strncpy(buf, inet_ntoa(a), buflen);
|
|
|
|
|
buf[buflen-1] = '\0';
|
2003-04-16 23:33:44 +00:00
|
|
|
#endif
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-28 10:56:19 +00: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 18:10:23 +00:00
|
|
|
static SockAddr sk_extractaddr_tmp(
|
|
|
|
|
SockAddr *addr, const SockAddrStep *step)
|
2017-01-28 10:56:19 +00:00
|
|
|
{
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
SockAddr toret;
|
2017-01-28 10:56:19 +00:00
|
|
|
toret = *addr; /* structure copy */
|
|
|
|
|
toret.refcount = 1;
|
|
|
|
|
|
|
|
|
|
if (addr->superfamily == IP) {
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
toret.ais = step->ai;
|
|
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
assert(SOCKADDR_FAMILY(addr, *step) == AF_INET);
|
2017-01-28 10:56:19 +00:00
|
|
|
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 19:23:19 +00:00
|
|
|
bool sk_addr_needs_port(SockAddr *addr)
|
2013-11-17 14:05:41 +00:00
|
|
|
{
|
|
|
|
|
if (addr->superfamily == UNRESOLVED || addr->superfamily == UNIX) {
|
2018-10-29 19:50:29 +00:00
|
|
|
return false;
|
2013-11-17 14:05:41 +00:00
|
|
|
} else {
|
2018-10-29 19:50:29 +00:00
|
|
|
return true;
|
2013-11-17 14:05:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool sk_hostname_is_local(const char *name)
|
2002-12-18 12:18:54 +00:00
|
|
|
{
|
2009-01-05 02:45:38 +00:00
|
|
|
return !strcmp(name, "localhost") ||
|
2019-09-08 19:29:00 +00:00
|
|
|
!strcmp(name, "::1") ||
|
|
|
|
|
!strncmp(name, "127.", 4);
|
2002-12-18 12:18:54 +00:00
|
|
|
}
|
|
|
|
|
|
2005-01-26 20:18:33 +00: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 19:23:19 +00:00
|
|
|
static bool sockaddr_is_loopback(struct sockaddr *sa)
|
2005-01-26 20:18:33 +00:00
|
|
|
{
|
2009-08-06 22:12:05 +00:00
|
|
|
union sockaddr_union *u = (union sockaddr_union *)sa;
|
|
|
|
|
switch (u->sa.sa_family) {
|
2005-01-26 20:18:33 +00:00
|
|
|
case AF_INET:
|
2019-09-08 19:29:00 +00:00
|
|
|
return ipv4_is_loopback(u->sin.sin_addr);
|
2005-01-26 20:18:33 +00:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
case AF_INET6:
|
2019-09-08 19:29:00 +00:00
|
|
|
return IN6_IS_ADDR_LOOPBACK(&u->sin6.sin6_addr);
|
2005-01-26 20:18:33 +00:00
|
|
|
#endif
|
2005-01-28 11:47:33 +00:00
|
|
|
case AF_UNIX:
|
2019-09-08 19:29:00 +00:00
|
|
|
return true;
|
2005-01-26 20:18:33 +00:00
|
|
|
default:
|
2019-09-08 19:29:00 +00:00
|
|
|
return false;
|
2005-01-26 20:18:33 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool sk_address_is_local(SockAddr *addr)
|
2002-12-18 12:18:54 +00:00
|
|
|
{
|
2008-11-08 16:45:45 +00:00
|
|
|
if (addr->superfamily == UNRESOLVED)
|
2019-09-08 19:29:00 +00:00
|
|
|
return false; /* we don't know; assume not */
|
2009-01-05 23:36:14 +00:00
|
|
|
else if (addr->superfamily == UNIX)
|
2019-09-08 19:29:00 +00:00
|
|
|
return true;
|
2003-04-16 23:33:44 +00:00
|
|
|
else {
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2019-09-08 19:29:00 +00:00
|
|
|
return sockaddr_is_loopback(addr->ais->ai_addr);
|
2003-04-16 23:33:44 +00:00
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
struct in_addr a;
|
|
|
|
|
SockAddrStep step;
|
|
|
|
|
START_STEP(addr, step);
|
|
|
|
|
assert(SOCKADDR_FAMILY(addr, step) == AF_INET);
|
|
|
|
|
a.s_addr = htonl(addr->addresses[0]);
|
|
|
|
|
return ipv4_is_loopback(a);
|
2003-04-16 23:33:44 +00:00
|
|
|
#endif
|
2002-12-18 12:18:54 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool sk_address_is_special_local(SockAddr *addr)
|
2012-10-16 20:15:51 +00: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 18:10:23 +00:00
|
|
|
int sk_addrtype(SockAddr *addr)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2014-02-05 21:51:25 +00:00
|
|
|
SockAddrStep step;
|
2008-11-08 16:45:45 +00:00
|
|
|
int family;
|
2014-02-05 21:51:25 +00:00
|
|
|
START_STEP(addr, step);
|
|
|
|
|
family = SOCKADDR_FAMILY(addr, step);
|
2008-11-08 16:45:45 +00:00
|
|
|
|
|
|
|
|
return (family == AF_INET ? ADDRTYPE_IPV4 :
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2019-09-08 19:29:00 +00:00
|
|
|
family == AF_INET6 ? ADDRTYPE_IPV6 :
|
2002-12-18 16:23:11 +00:00
|
|
|
#endif
|
2019-09-08 19:29:00 +00:00
|
|
|
ADDRTYPE_NAME);
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
void sk_addrcopy(SockAddr *addr, char *buf)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2008-11-08 16:45:45 +00:00
|
|
|
SockAddrStep step;
|
|
|
|
|
int family;
|
|
|
|
|
START_STEP(addr, step);
|
|
|
|
|
family = SOCKADDR_FAMILY(addr, step);
|
2003-04-16 23:33:44 +00:00
|
|
|
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2008-11-08 16:45:45 +00:00
|
|
|
if (family == AF_INET)
|
2019-09-08 19:29:00 +00:00
|
|
|
memcpy(buf, &((struct sockaddr_in *)step.ai->ai_addr)->sin_addr,
|
|
|
|
|
sizeof(struct in_addr));
|
2008-11-08 16:45:45 +00:00
|
|
|
else if (family == AF_INET6)
|
2019-09-08 19:29:00 +00:00
|
|
|
memcpy(buf, &((struct sockaddr_in6 *)step.ai->ai_addr)->sin6_addr,
|
|
|
|
|
sizeof(struct in6_addr));
|
2003-04-16 23:33:44 +00:00
|
|
|
else
|
2019-09-08 19:29:00 +00:00
|
|
|
unreachable("bad address family in sk_addrcopy");
|
2003-04-16 23:33:44 +00:00
|
|
|
#else
|
|
|
|
|
struct in_addr a;
|
|
|
|
|
|
2008-11-08 16:45:45 +00:00
|
|
|
assert(family == AF_INET);
|
|
|
|
|
a.s_addr = htonl(addr->addresses[step.curraddr]);
|
2003-04-16 23:33:44 +00:00
|
|
|
memcpy(buf, (char*) &a.s_addr, 4);
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
void sk_addr_free(SockAddr *addr)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2008-11-08 16:58:55 +00:00
|
|
|
if (--addr->refcount > 0)
|
2019-09-08 19:29:00 +00:00
|
|
|
return;
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2005-01-16 14:29:34 +00:00
|
|
|
if (addr->ais != NULL)
|
2019-09-08 19:29:00 +00:00
|
|
|
freeaddrinfo(addr->ais);
|
2005-01-16 14:29:34 +00:00
|
|
|
#else
|
|
|
|
|
sfree(addr->addresses);
|
2003-04-16 23:33:44 +00:00
|
|
|
#endif
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
SockAddr *sk_addr_dup(SockAddr *addr)
|
2008-11-08 16:58:55 +00: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 18:10:23 +00:00
|
|
|
static Plug *sk_net_plug(Socket *sock, Plug *p)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00: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 18:10:23 +00:00
|
|
|
Plug *ret = s->plug;
|
2002-10-31 19:49:52 +00:00
|
|
|
if (p)
|
2019-09-08 19:29:00 +00:00
|
|
|
s->plug = p;
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
static void sk_net_close(Socket *s);
|
2019-02-06 20:42:44 +00: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 18:10:23 +00: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 19:23:19 +00:00
|
|
|
static void sk_net_set_frozen(Socket *s, bool is_frozen);
|
2024-06-26 05:47:53 +00:00
|
|
|
static SocketEndpointInfo *sk_net_endpoint_info(Socket *s, bool peer);
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
static const char *sk_net_socket_error(Socket *s);
|
2018-05-27 08:29:33 +00:00
|
|
|
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
static const SocketVtable NetSocket_sockvt = {
|
|
|
|
|
.plug = sk_net_plug,
|
|
|
|
|
.close = sk_net_close,
|
|
|
|
|
.write = sk_net_write,
|
|
|
|
|
.write_oob = sk_net_write_oob,
|
|
|
|
|
.write_eof = sk_net_write_eof,
|
|
|
|
|
.set_frozen = sk_net_set_frozen,
|
|
|
|
|
.socket_error = sk_net_socket_error,
|
2024-06-26 05:47:53 +00:00
|
|
|
.endpoint_info = sk_net_endpoint_info,
|
2003-01-11 09:31:54 +00:00
|
|
|
};
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
static Socket *sk_net_accept(accept_ctx_t ctx, Plug *plug)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2013-11-17 14:03:55 +00:00
|
|
|
int sockfd = ctx.i;
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
NetSocket *s;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
|
|
|
|
/*
|
2018-05-27 08:29:33 +00:00
|
|
|
* Create NetSocket structure.
|
2002-10-31 19:49:52 +00:00
|
|
|
*/
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s = snew(NetSocket);
|
|
|
|
|
s->sock.vt = &NetSocket_sockvt;
|
|
|
|
|
s->error = NULL;
|
|
|
|
|
s->plug = plug;
|
|
|
|
|
bufchain_init(&s->output_data);
|
|
|
|
|
s->writable = true; /* to start with */
|
|
|
|
|
s->sending_oob = 0;
|
|
|
|
|
s->frozen = true;
|
|
|
|
|
s->localhost_only = false; /* unused, but best init anyway */
|
|
|
|
|
s->pending_error = 0;
|
|
|
|
|
s->oobpending = false;
|
|
|
|
|
s->outgoingeof = EOF_NO;
|
|
|
|
|
s->incomingeof = false;
|
|
|
|
|
s->listener = false;
|
|
|
|
|
s->parent = s->child = NULL;
|
|
|
|
|
s->addr = NULL;
|
|
|
|
|
s->connected = true;
|
|
|
|
|
|
|
|
|
|
s->s = sockfd;
|
|
|
|
|
|
|
|
|
|
if (s->s < 0) {
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->oobinline = false;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
uxsel_tell(s);
|
|
|
|
|
add234(sktree, s);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-27 08:29:33 +00:00
|
|
|
static int try_connect(NetSocket *sock)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
|
|
|
|
int s;
|
2009-08-06 22:55:15 +00:00
|
|
|
union sockaddr_union u;
|
|
|
|
|
const union sockaddr_union *sa;
|
2005-01-16 14:29:34 +00:00
|
|
|
int err = 0;
|
2002-10-31 19:49:52 +00:00
|
|
|
short localport;
|
2013-07-19 18:10:02 +00:00
|
|
|
int salen, family;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2007-11-28 20:45:50 +00: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 14:29:34 +00:00
|
|
|
if (sock->s >= 0)
|
|
|
|
|
close(sock->s);
|
|
|
|
|
|
2017-01-28 10:56:19 +00:00
|
|
|
{
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
SockAddr thisaddr = sk_extractaddr_tmp(
|
2017-01-28 10:56:19 +00:00
|
|
|
sock->addr, &sock->step);
|
2024-06-26 07:29:39 +00:00
|
|
|
plug_log(sock->plug, &sock->sock, PLUGLOG_CONNECT_TRYING,
|
2020-02-07 19:17:45 +00:00
|
|
|
&thisaddr, sock->port, NULL, 0);
|
2017-01-28 10:56:19 +00:00
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Open socket.
|
|
|
|
|
*/
|
2008-11-08 16:45:45 +00:00
|
|
|
family = SOCKADDR_FAMILY(sock->addr, sock->step);
|
|
|
|
|
assert(family != AF_UNSPEC);
|
|
|
|
|
s = socket(family, SOCK_STREAM, 0);
|
2005-01-16 14:29:34 +00:00
|
|
|
sock->s = s;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
|
|
|
|
if (s < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
err = errno;
|
|
|
|
|
goto ret;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2006-12-09 15:44:31 +00:00
|
|
|
cloexec(s);
|
2006-11-23 14:32:11 +00:00
|
|
|
|
2005-01-16 14:29:34 +00:00
|
|
|
if (sock->oobinline) {
|
2019-09-08 19:29:00 +00:00
|
|
|
int b = 1;
|
|
|
|
|
if (setsockopt(s, SOL_SOCKET, SO_OOBINLINE,
|
2013-07-19 17:45:01 +00:00
|
|
|
(void *) &b, sizeof(b)) < 0) {
|
|
|
|
|
err = errno;
|
|
|
|
|
close(s);
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2020-02-16 16:22:17 +00:00
|
|
|
if (sock->nodelay && family != AF_UNIX) {
|
2019-09-08 19:29:00 +00:00
|
|
|
int b = 1;
|
|
|
|
|
if (setsockopt(s, IPPROTO_TCP, TCP_NODELAY,
|
2013-07-19 17:45:01 +00:00
|
|
|
(void *) &b, sizeof(b)) < 0) {
|
|
|
|
|
err = errno;
|
|
|
|
|
close(s);
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2005-01-16 14:29:34 +00:00
|
|
|
if (sock->keepalive) {
|
2019-09-08 19:29:00 +00:00
|
|
|
int b = 1;
|
|
|
|
|
if (setsockopt(s, SOL_SOCKET, SO_KEEPALIVE,
|
2013-07-19 17:45:01 +00:00
|
|
|
(void *) &b, sizeof(b)) < 0) {
|
|
|
|
|
err = errno;
|
|
|
|
|
close(s);
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2004-06-20 17:07:38 +00:00
|
|
|
}
|
|
|
|
|
|
2002-10-31 19:49:52 +00:00
|
|
|
/*
|
|
|
|
|
* Bind to local address.
|
|
|
|
|
*/
|
2005-01-16 14:29:34 +00:00
|
|
|
if (sock->privport)
|
2019-09-08 19:29:00 +00:00
|
|
|
localport = 1023; /* count from 1023 downwards */
|
2002-10-31 19:49:52 +00:00
|
|
|
else
|
2019-09-08 19:29:00 +00:00
|
|
|
localport = 0; /* just use port 0 (ie kernel picks) */
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2004-02-03 14:47:43 +00:00
|
|
|
/* BSD IP stacks need sockaddr_in zeroed before filling in */
|
2009-08-06 22:55:15 +00:00
|
|
|
memset(&u,'\0',sizeof(u));
|
2004-05-31 14:01:52 +00: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 16:45:45 +00:00
|
|
|
if (family != AF_UNIX) {
|
2019-09-08 19:29:00 +00:00
|
|
|
/* Loop round trying to bind */
|
|
|
|
|
while (1) {
|
|
|
|
|
int retcode;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2019-09-08 19:29:00 +00:00
|
|
|
if (family == AF_INET6) {
|
|
|
|
|
/* XXX use getaddrinfo to get a local address? */
|
|
|
|
|
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));
|
|
|
|
|
} else
|
2002-10-31 19:49:52 +00:00
|
|
|
#endif
|
2019-09-08 19:29:00 +00:00
|
|
|
{
|
|
|
|
|
assert(family == AF_INET);
|
|
|
|
|
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));
|
|
|
|
|
}
|
|
|
|
|
if (retcode >= 0) {
|
|
|
|
|
err = 0;
|
|
|
|
|
break; /* done */
|
|
|
|
|
} else {
|
|
|
|
|
err = errno;
|
|
|
|
|
if (err != EADDRINUSE) /* failed, for a bad reason */
|
2022-08-03 19:48:46 +00:00
|
|
|
break;
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (localport == 0)
|
2022-08-03 19:48:46 +00:00
|
|
|
break; /* we're only looping once */
|
2019-09-08 19:29:00 +00:00
|
|
|
localport--;
|
|
|
|
|
if (localport == 0)
|
2022-08-03 19:48:46 +00:00
|
|
|
break; /* we might have got to the end */
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
goto ret;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Connect to remote address.
|
|
|
|
|
*/
|
2008-11-08 16:45:45 +00:00
|
|
|
switch(family) {
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2004-05-31 14:01:52 +00:00
|
|
|
case AF_INET:
|
2019-09-08 19:29:00 +00:00
|
|
|
/* XXX would be better to have got getaddrinfo() to fill in the port. */
|
|
|
|
|
((struct sockaddr_in *)sock->step.ai->ai_addr)->sin_port =
|
|
|
|
|
htons(sock->port);
|
|
|
|
|
sa = (const union sockaddr_union *)sock->step.ai->ai_addr;
|
|
|
|
|
salen = sock->step.ai->ai_addrlen;
|
|
|
|
|
break;
|
2004-05-31 14:01:52 +00:00
|
|
|
case AF_INET6:
|
2019-09-08 19:29:00 +00:00
|
|
|
((struct sockaddr_in *)sock->step.ai->ai_addr)->sin_port =
|
|
|
|
|
htons(sock->port);
|
|
|
|
|
sa = (const union sockaddr_union *)sock->step.ai->ai_addr;
|
|
|
|
|
salen = sock->step.ai->ai_addrlen;
|
|
|
|
|
break;
|
2003-04-16 23:33:44 +00:00
|
|
|
#else
|
2004-05-31 14:01:52 +00:00
|
|
|
case AF_INET:
|
2019-09-08 19:29:00 +00: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;
|
|
|
|
|
break;
|
2003-04-16 23:33:44 +00:00
|
|
|
#endif
|
2004-05-31 14:01:52 +00:00
|
|
|
case AF_UNIX:
|
2019-09-08 19:29:00 +00: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;
|
|
|
|
|
break;
|
2004-05-31 14:01:52 +00:00
|
|
|
|
|
|
|
|
default:
|
2019-09-08 19:29:00 +00:00
|
|
|
unreachable("unknown address family");
|
|
|
|
|
exit(1); /* XXX: GCC doesn't understand assert() on some systems. */
|
2004-05-31 14:01:52 +00:00
|
|
|
}
|
2003-04-16 23:58:59 +00:00
|
|
|
|
2013-07-19 18:10:02 +00:00
|
|
|
nonblock(s);
|
2003-01-09 18:14:24 +00:00
|
|
|
|
2009-08-06 22:55:15 +00:00
|
|
|
if ((connect(s, &(sa->sa), salen)) < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if ( errno != EINPROGRESS ) {
|
|
|
|
|
err = errno;
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
} else {
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
|
* If we _don't_ get EWOULDBLOCK, the connect has completed
|
|
|
|
|
* and we should set the socket as connected and writable.
|
|
|
|
|
*/
|
|
|
|
|
sock->connected = true;
|
|
|
|
|
sock->writable = true;
|
2020-02-07 19:18:50 +00:00
|
|
|
|
|
|
|
|
SockAddr thisaddr = sk_extractaddr_tmp(sock->addr, &sock->step);
|
2024-06-26 07:29:39 +00:00
|
|
|
plug_log(sock->plug, &sock->sock, PLUGLOG_CONNECT_SUCCESS,
|
2020-02-07 19:18:50 +00:00
|
|
|
&thisaddr, sock->port, NULL, 0);
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2005-01-16 14:29:34 +00:00
|
|
|
uxsel_tell(sock);
|
|
|
|
|
|
2022-08-03 19:48:46 +00:00
|
|
|
ret:
|
2007-11-28 20:45:50 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* No matter what happened, put the socket back in the tree.
|
|
|
|
|
*/
|
|
|
|
|
add234(sktree, sock);
|
|
|
|
|
|
2017-01-28 10:56:19 +00: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 18:10:23 +00:00
|
|
|
SockAddr thisaddr = sk_extractaddr_tmp(
|
2017-01-28 10:56:19 +00:00
|
|
|
sock->addr, &sock->step);
|
2024-06-26 07:29:39 +00:00
|
|
|
plug_log(sock->plug, &sock->sock, PLUGLOG_CONNECT_FAILED,
|
2020-02-07 19:17:45 +00:00
|
|
|
&thisaddr, sock->port, strerror(err), err);
|
2017-01-28 10:56:19 +00:00
|
|
|
}
|
2005-01-16 14:29:34 +00: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 19:23:19 +00:00
|
|
|
Socket *sk_new(SockAddr *addr, int port, bool privport, bool oobinline,
|
|
|
|
|
bool nodelay, bool keepalive, Plug *plug)
|
2005-01-16 14:29:34 +00:00
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
NetSocket *s;
|
2005-01-16 14:29:34 +00:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/*
|
2018-05-27 08:29:33 +00:00
|
|
|
* Create NetSocket structure.
|
2005-01-16 14:29:34 +00:00
|
|
|
*/
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s = snew(NetSocket);
|
|
|
|
|
s->sock.vt = &NetSocket_sockvt;
|
|
|
|
|
s->error = NULL;
|
|
|
|
|
s->plug = plug;
|
|
|
|
|
bufchain_init(&s->output_data);
|
|
|
|
|
s->connected = false; /* to start with */
|
|
|
|
|
s->writable = false; /* to start with */
|
|
|
|
|
s->sending_oob = 0;
|
|
|
|
|
s->frozen = false;
|
|
|
|
|
s->localhost_only = false; /* unused, but best init anyway */
|
|
|
|
|
s->pending_error = 0;
|
|
|
|
|
s->parent = s->child = NULL;
|
|
|
|
|
s->oobpending = false;
|
|
|
|
|
s->outgoingeof = EOF_NO;
|
|
|
|
|
s->incomingeof = false;
|
|
|
|
|
s->listener = false;
|
|
|
|
|
s->addr = addr;
|
|
|
|
|
START_STEP(s->addr, s->step);
|
|
|
|
|
s->s = -1;
|
|
|
|
|
s->oobinline = oobinline;
|
|
|
|
|
s->nodelay = nodelay;
|
|
|
|
|
s->keepalive = keepalive;
|
|
|
|
|
s->privport = privport;
|
|
|
|
|
s->port = port;
|
2005-01-16 14:29:34 +00:00
|
|
|
|
|
|
|
|
do {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
err = try_connect(s);
|
|
|
|
|
} while (err && sk_nextaddr(s->addr, &s->step));
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2005-01-16 14:29:34 +00:00
|
|
|
if (err)
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->error = strerror(err);
|
2003-08-07 16:04:33 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
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 19:23:19 +00:00
|
|
|
bool local_host_only, int orig_address_family)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
int fd;
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2014-12-20 16:54:28 +00:00
|
|
|
struct addrinfo hints, *ai = NULL;
|
2003-04-16 23:33:44 +00:00
|
|
|
char portstr[6];
|
2002-10-31 19:49:52 +00:00
|
|
|
#endif
|
2009-08-06 22:55:15 +00:00
|
|
|
union sockaddr_union u;
|
|
|
|
|
union sockaddr_union *addr;
|
2005-01-16 12:37:19 +00:00
|
|
|
int addrlen;
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
NetSocket *s;
|
2002-10-31 19:49:52 +00:00
|
|
|
int retcode;
|
2008-08-20 22:21:04 +00:00
|
|
|
int address_family;
|
2002-10-31 19:49:52 +00:00
|
|
|
int on = 1;
|
|
|
|
|
|
|
|
|
|
/*
|
2018-05-27 08:29:33 +00:00
|
|
|
* Create NetSocket structure.
|
2002-10-31 19:49:52 +00:00
|
|
|
*/
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s = snew(NetSocket);
|
|
|
|
|
s->sock.vt = &NetSocket_sockvt;
|
|
|
|
|
s->error = NULL;
|
|
|
|
|
s->plug = plug;
|
|
|
|
|
bufchain_init(&s->output_data);
|
|
|
|
|
s->writable = false; /* to start with */
|
|
|
|
|
s->sending_oob = 0;
|
|
|
|
|
s->frozen = false;
|
|
|
|
|
s->localhost_only = local_host_only;
|
|
|
|
|
s->pending_error = 0;
|
|
|
|
|
s->parent = s->child = NULL;
|
|
|
|
|
s->oobpending = false;
|
|
|
|
|
s->outgoingeof = EOF_NO;
|
|
|
|
|
s->incomingeof = false;
|
|
|
|
|
s->listener = true;
|
|
|
|
|
s->addr = NULL;
|
|
|
|
|
s->s = -1;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2004-12-30 16:45:11 +00:00
|
|
|
/*
|
|
|
|
|
* Translate address_family from platform-independent constants
|
|
|
|
|
* into local reality.
|
|
|
|
|
*/
|
2008-08-20 22:21:04 +00:00
|
|
|
address_family = (orig_address_family == ADDRTYPE_IPV4 ? AF_INET :
|
2005-09-13 19:54:01 +00:00
|
|
|
#ifndef NO_IPV6
|
2019-09-08 19:29:00 +00:00
|
|
|
orig_address_family == ADDRTYPE_IPV6 ? AF_INET6 :
|
2005-09-13 19:54:01 +00:00
|
|
|
#endif
|
2019-09-08 19:29:00 +00:00
|
|
|
AF_UNSPEC);
|
2004-12-30 16:45:11 +00: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 19:49:52 +00:00
|
|
|
/*
|
|
|
|
|
* Open socket.
|
|
|
|
|
*/
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
fd = socket(address_family, SOCK_STREAM, 0);
|
2004-12-30 16:45:11 +00:00
|
|
|
|
2005-09-13 19:54:01 +00:00
|
|
|
#ifndef NO_IPV6
|
2004-12-30 16:45:11 +00:00
|
|
|
/* If the host doesn't support IPv6 try fallback to IPv4. */
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
if (fd < 0 && address_family == AF_INET6) {
|
2019-09-08 19:29:00 +00:00
|
|
|
address_family = AF_INET;
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
fd = socket(address_family, SOCK_STREAM, 0);
|
2004-12-30 16:45:11 +00:00
|
|
|
}
|
2005-09-13 19:54:01 +00:00
|
|
|
#endif
|
2002-10-31 19:49:52 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
if (fd < 0) {
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
cloexec(fd);
|
2006-11-23 14:32:11 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->oobinline = false;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
|
2013-07-19 17:45:01 +00:00
|
|
|
(const char *)&on, sizeof(on)) < 0) {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->error = strerror(errno);
|
|
|
|
|
close(fd);
|
|
|
|
|
return &s->sock;
|
2013-07-19 17:45:01 +00:00
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2005-01-16 12:37:19 +00:00
|
|
|
retcode = -1;
|
|
|
|
|
addr = NULL; addrlen = -1; /* placate optimiser */
|
|
|
|
|
|
|
|
|
|
if (srcaddr != NULL) {
|
2004-12-30 16:45:11 +00:00
|
|
|
#ifndef NO_IPV6
|
2005-01-16 12:37:19 +00:00
|
|
|
hints.ai_flags = AI_NUMERICHOST;
|
|
|
|
|
hints.ai_family = address_family;
|
2005-01-22 15:32:10 +00:00
|
|
|
hints.ai_socktype = SOCK_STREAM;
|
2005-01-16 12:37:19 +00:00
|
|
|
hints.ai_protocol = 0;
|
|
|
|
|
hints.ai_addrlen = 0;
|
|
|
|
|
hints.ai_addr = NULL;
|
|
|
|
|
hints.ai_canonname = NULL;
|
|
|
|
|
hints.ai_next = NULL;
|
2019-09-08 19:29:00 +00:00
|
|
|
assert(port >= 0 && port <= 99999);
|
2005-01-16 12:37:19 +00:00
|
|
|
sprintf(portstr, "%d", port);
|
2014-01-25 15:58:54 +00:00
|
|
|
{
|
|
|
|
|
char *trimmed_addr = host_strduptrim(srcaddr);
|
|
|
|
|
retcode = getaddrinfo(trimmed_addr, portstr, &hints, &ai);
|
|
|
|
|
sfree(trimmed_addr);
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
if (retcode == 0) {
|
|
|
|
|
addr = (union sockaddr_union *)ai->ai_addr;
|
|
|
|
|
addrlen = ai->ai_addrlen;
|
|
|
|
|
}
|
2005-01-16 12:37:19 +00:00
|
|
|
#else
|
2009-08-06 22:55:15 +00: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 12:37:19 +00:00
|
|
|
/* Override localhost_only with specified listen addr. */
|
2009-08-06 22:55:15 +00:00
|
|
|
ret->localhost_only = ipv4_is_loopback(u.sin.sin_addr);
|
2005-01-16 12:37:19 +00:00
|
|
|
}
|
2009-08-06 22:55:15 +00:00
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.sin);
|
2005-01-16 12:37:19 +00:00
|
|
|
retcode = 0;
|
2002-10-31 19:49:52 +00:00
|
|
|
#endif
|
2005-01-16 12:37:19 +00:00
|
|
|
}
|
2002-12-18 11:39:25 +00:00
|
|
|
|
2005-01-16 12:37:19 +00:00
|
|
|
if (retcode != 0) {
|
2009-08-06 22:55:15 +00:00
|
|
|
memset(&u,'\0',sizeof u);
|
2005-01-16 12:37:19 +00:00
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
if (address_family == AF_INET6) {
|
2009-08-06 22:55:15 +00:00
|
|
|
u.sin6.sin6_family = AF_INET6;
|
|
|
|
|
u.sin6.sin6_port = htons(port);
|
2005-01-16 12:37:19 +00:00
|
|
|
if (local_host_only)
|
2009-08-06 22:55:15 +00:00
|
|
|
u.sin6.sin6_addr = in6addr_loopback;
|
2005-01-16 12:37:19 +00:00
|
|
|
else
|
2009-08-06 22:55:15 +00:00
|
|
|
u.sin6.sin6_addr = in6addr_any;
|
|
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.sin6);
|
2005-01-16 12:37:19 +00:00
|
|
|
} else
|
|
|
|
|
#endif
|
|
|
|
|
{
|
2009-08-06 22:55:15 +00:00
|
|
|
u.sin.sin_family = AF_INET;
|
|
|
|
|
u.sin.sin_port = htons(port);
|
2019-09-08 19:29:00 +00:00
|
|
|
if (local_host_only)
|
|
|
|
|
u.sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
|
|
|
|
|
else
|
|
|
|
|
u.sin.sin_addr.s_addr = htonl(INADDR_ANY);
|
2009-08-06 22:55:15 +00:00
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.sin);
|
2005-01-16 12:37:19 +00:00
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
retcode = bind(fd, &addr->sa, addrlen);
|
2014-12-20 16:54:28 +00:00
|
|
|
|
|
|
|
|
#ifndef NO_IPV6
|
|
|
|
|
if (ai)
|
|
|
|
|
freeaddrinfo(ai);
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-01-16 12:37:19 +00:00
|
|
|
if (retcode < 0) {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
close(fd);
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
if (listen(fd, SOMAXCONN) < 0) {
|
|
|
|
|
close(fd);
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2008-08-20 22:21:04 +00: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 08:29:33 +00:00
|
|
|
NetSocket *other;
|
2008-08-20 22:21:04 +00:00
|
|
|
|
2018-10-05 22:49:08 +00:00
|
|
|
other = container_of(
|
2018-05-27 08:29:33 +00:00
|
|
|
sk_newlistener(srcaddr, port, plug,
|
|
|
|
|
local_host_only, ADDRTYPE_IPV4),
|
2018-10-05 06:24:16 +00:00
|
|
|
NetSocket, sock);
|
2008-08-20 22:21:04 +00:00
|
|
|
|
|
|
|
|
if (other) {
|
|
|
|
|
if (!other->error) {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
other->parent = s;
|
|
|
|
|
s->child = other;
|
2008-08-20 22:21:04 +00:00
|
|
|
} else {
|
|
|
|
|
/* If we couldn't create a listening socket on IPv4 as well
|
|
|
|
|
* as IPv6, we must return an error overall. */
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
close(fd);
|
|
|
|
|
sfree(s);
|
2018-10-05 06:24:16 +00:00
|
|
|
return &other->sock;
|
2008-08-20 22:21:04 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->s = fd;
|
2005-01-16 12:37:19 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
uxsel_tell(s);
|
|
|
|
|
add234(sktree, s);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
return &s->sock;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
static void sk_net_close(Socket *sock)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2008-08-20 22:21:04 +00:00
|
|
|
if (s->child)
|
2018-10-05 06:24:16 +00:00
|
|
|
sk_net_close(&s->child->sock);
|
2008-08-20 22:21:04 +00:00
|
|
|
|
2019-01-29 20:13:47 +00:00
|
|
|
bufchain_clear(&s->output_data);
|
|
|
|
|
|
2002-10-31 19:49:52 +00:00
|
|
|
del234(sktree, s);
|
2017-10-01 20:05:25 +00:00
|
|
|
if (s->s >= 0) {
|
|
|
|
|
uxsel_del(s->s);
|
|
|
|
|
close(s->s);
|
|
|
|
|
}
|
2005-01-16 14:29:34 +00:00
|
|
|
if (s->addr)
|
|
|
|
|
sk_addr_free(s->addr);
|
2019-01-29 20:15:43 +00:00
|
|
|
delete_callbacks_for_context(s);
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
void *sk_getxdmdata(Socket *sock, int *lenp)
|
2003-01-11 09:31:54 +00:00
|
|
|
{
|
2018-05-27 08:29:33 +00:00
|
|
|
NetSocket *s;
|
2009-08-06 22:12:05 +00:00
|
|
|
union sockaddr_union u;
|
2003-01-11 09:31:54 +00:00
|
|
|
socklen_t addrlen;
|
2005-01-28 11:39:45 +00:00
|
|
|
char *buf;
|
|
|
|
|
static unsigned int unix_addr = 0xFFFFFFFF;
|
2003-01-11 09:31:54 +00:00
|
|
|
|
|
|
|
|
/*
|
2018-05-27 08:29:33 +00:00
|
|
|
* We must check that this socket really _is_ a NetSocket before
|
|
|
|
|
* downcasting it.
|
2003-01-11 09:31:54 +00:00
|
|
|
*/
|
2018-10-05 06:24:16 +00:00
|
|
|
if (sock->vt != &NetSocket_sockvt)
|
2019-09-08 19:29:00 +00:00
|
|
|
return NULL; /* failure */
|
2018-10-05 22:49:08 +00:00
|
|
|
s = container_of(sock, NetSocket, sock);
|
2003-01-11 09:31:54 +00:00
|
|
|
|
2009-08-06 22:12:05 +00:00
|
|
|
addrlen = sizeof(u);
|
|
|
|
|
if (getsockname(s->s, &u.sa, &addrlen) < 0)
|
2019-09-08 19:29:00 +00:00
|
|
|
return NULL;
|
2009-08-06 22:12:05 +00:00
|
|
|
switch(u.sa.sa_family) {
|
2004-05-31 14:01:52 +00:00
|
|
|
case AF_INET:
|
2019-09-08 19:29:00 +00:00
|
|
|
*lenp = 6;
|
|
|
|
|
buf = snewn(*lenp, char);
|
|
|
|
|
PUT_32BIT_MSB_FIRST(buf, ntohl(u.sin.sin_addr.s_addr));
|
|
|
|
|
PUT_16BIT_MSB_FIRST(buf+4, ntohs(u.sin.sin_port));
|
|
|
|
|
break;
|
2005-01-28 11:39:45 +00:00
|
|
|
#ifndef NO_IPV6
|
2022-08-03 19:48:46 +00:00
|
|
|
case AF_INET6:
|
2019-09-08 19:29:00 +00:00
|
|
|
*lenp = 6;
|
|
|
|
|
buf = snewn(*lenp, char);
|
|
|
|
|
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));
|
|
|
|
|
} else
|
|
|
|
|
/* This is stupid, but it's what XLib does. */
|
|
|
|
|
memset(buf, 0, 6);
|
|
|
|
|
break;
|
2005-01-28 11:39:45 +00:00
|
|
|
#endif
|
2004-05-31 14:01:52 +00:00
|
|
|
case AF_UNIX:
|
2019-09-08 19:29:00 +00:00
|
|
|
*lenp = 6;
|
|
|
|
|
buf = snewn(*lenp, char);
|
|
|
|
|
PUT_32BIT_MSB_FIRST(buf, unix_addr--);
|
2005-01-28 11:39:45 +00:00
|
|
|
PUT_16BIT_MSB_FIRST(buf+4, getpid());
|
2019-09-08 19:29:00 +00:00
|
|
|
break;
|
2003-01-11 09:31:54 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
/* XXX IPV6 */
|
2004-05-31 14:01:52 +00:00
|
|
|
|
|
|
|
|
default:
|
2019-09-08 19:29:00 +00:00
|
|
|
return NULL;
|
2004-05-31 14:01:52 +00:00
|
|
|
}
|
2003-01-11 09:31:54 +00:00
|
|
|
|
2005-01-28 11:39:45 +00:00
|
|
|
return buf;
|
2003-01-11 09:31:54 +00:00
|
|
|
}
|
|
|
|
|
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
void plug_closing_errno(Plug *plug, int error)
|
|
|
|
|
{
|
New API for plug_closing() with a custom type enum.
Passing an operating-system-specific error code to plug_closing(),
such as errno or GetLastError(), was always a bit weird, given that it
generally had to be handled by cross-platform receiving code in
backends. I had the platform.h implementations #define any error
values that the cross-platform code would have to handle specially,
but that's still not a great system, because it also doesn't leave
freedom to invent error representations of my own that don't
correspond to any OS code. (For example, the ones I just removed from
proxy.h.)
So now, the OS error code is gone from the plug_closing API, and in
its place is a custom enumeration of closure types: normal, error, and
the special case BROKEN_PIPE which is the only OS error code we have
so far needed to handle specially. (All others just mean 'abandon the
connection and print the textual message'.)
Having already centralised the handling of OS error codes in the
previous commit, we've now got a convenient place to add any further
type codes for errors needing special handling: each of Unix
plug_closing_errno(), Windows plug_closing_system_error(), and Windows
plug_closing_winsock_error() can easily grow extra special cases if
need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
|
|
|
PlugCloseType type = PLUGCLOSE_ERROR;
|
|
|
|
|
if (error == EPIPE)
|
|
|
|
|
type = PLUGCLOSE_BROKEN_PIPE;
|
|
|
|
|
plug_closing(plug, type, strerror(error));
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-08-17 16:06:27 +00:00
|
|
|
/*
|
|
|
|
|
* Deal with socket errors detected in try_send().
|
|
|
|
|
*/
|
|
|
|
|
static void socket_error_callback(void *vs)
|
|
|
|
|
{
|
2018-05-27 08:29:33 +00:00
|
|
|
NetSocket *s = (NetSocket *)vs;
|
2013-08-17 16:06:27 +00: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.
|
|
|
|
|
*/
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
plug_closing_errno(s->plug, s->pending_error);
|
2013-08-17 16:06:27 +00:00
|
|
|
}
|
|
|
|
|
|
2002-10-31 19:49:52 +00:00
|
|
|
/*
|
|
|
|
|
* The function which tries to send on a socket once it's deemed
|
|
|
|
|
* writable.
|
|
|
|
|
*/
|
2018-05-27 08:29:33 +00:00
|
|
|
void try_send(NetSocket *s)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
|
|
|
|
while (s->sending_oob || bufchain_size(&s->output_data) > 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
int nsent;
|
|
|
|
|
int err;
|
|
|
|
|
const void *data;
|
|
|
|
|
size_t len;
|
2019-02-06 20:42:44 +00:00
|
|
|
int urgentflag;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if (s->sending_oob) {
|
|
|
|
|
urgentflag = MSG_OOB;
|
|
|
|
|
len = s->sending_oob;
|
|
|
|
|
data = &s->oobdata;
|
|
|
|
|
} else {
|
|
|
|
|
urgentflag = 0;
|
2019-02-06 20:46:45 +00:00
|
|
|
ptrlen bufdata = bufchain_prefix(&s->output_data);
|
|
|
|
|
data = bufdata.ptr;
|
|
|
|
|
len = bufdata.len;
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
|
nsent = send(s->s, data, len, urgentflag);
|
|
|
|
|
noise_ultralight(NOISE_SOURCE_IOLEN, nsent);
|
|
|
|
|
if (nsent <= 0) {
|
|
|
|
|
err = (nsent < 0 ? errno : 0);
|
|
|
|
|
if (err == EWOULDBLOCK) {
|
|
|
|
|
/*
|
|
|
|
|
* Perfectly normal: we've sent all we can for the moment.
|
|
|
|
|
*/
|
|
|
|
|
s->writable = false;
|
|
|
|
|
return;
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* We unfortunately can't just call plug_closing(),
|
|
|
|
|
* 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 19:15:57 +00: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 16:06:27 +00:00
|
|
|
* Arrange to be called back from the top level to
|
|
|
|
|
* deal with the error condition on this socket.
|
2011-12-08 19:15:57 +00:00
|
|
|
*/
|
2013-08-17 16:06:27 +00:00
|
|
|
queue_toplevel_callback(socket_error_callback, s);
|
2019-09-08 19:29:00 +00: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);
|
|
|
|
|
}
|
|
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
2011-09-13 11:44:03 +00: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 16:47:06 +00:00
|
|
|
uxsel_tell(s);
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-02-06 20:42:44 +00:00
|
|
|
static size_t sk_net_write(Socket *sock, const void *buf, size_t len)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2011-09-13 11:44:03 +00:00
|
|
|
assert(s->outgoingeof == EOF_NO);
|
|
|
|
|
|
2002-10-31 19:49:52 +00: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)
|
2019-09-08 19:29:00 +00:00
|
|
|
try_send(s);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2003-04-18 09:00:37 +00:00
|
|
|
/*
|
|
|
|
|
* Update the select() status to correctly reflect whether or
|
|
|
|
|
* not we should be selecting for write.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
|
2002-10-31 19:49:52 +00:00
|
|
|
return bufchain_size(&s->output_data);
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-06 20:42:44 +00:00
|
|
|
static size_t sk_net_write_oob(Socket *sock, const void *buf, size_t len)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2011-09-13 11:44:03 +00:00
|
|
|
assert(s->outgoingeof == EOF_NO);
|
|
|
|
|
|
2002-10-31 19:49:52 +00: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)
|
2019-09-08 19:29:00 +00:00
|
|
|
try_send(s);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2003-04-18 09:00:37 +00:00
|
|
|
/*
|
|
|
|
|
* Update the select() status to correctly reflect whether or
|
|
|
|
|
* not we should be selecting for write.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
static void sk_net_write_eof(Socket *sock)
|
2011-09-13 11:44:03 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2011-09-13 11:44:03 +00: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)
|
2019-09-08 19:29:00 +00:00
|
|
|
try_send(s);
|
2011-09-13 11:44:03 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Update the select() status to correctly reflect whether or
|
|
|
|
|
* not we should be selecting for write.
|
|
|
|
|
*/
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-30 21:52:30 +00:00
|
|
|
static void net_select_result(int fd, int event)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
|
|
|
|
int ret;
|
2019-09-08 19:29:00 +00:00
|
|
|
char buf[20480]; /* nice big buffer for plenty of speed */
|
2018-05-27 08:29:33 +00:00
|
|
|
NetSocket *s;
|
2018-11-03 17:04:14 +00:00
|
|
|
bool atmark = true;
|
2002-10-31 19:49:52 +00:00
|
|
|
|
|
|
|
|
/* Find the Socket structure */
|
2003-05-10 08:35:54 +00:00
|
|
|
s = find234(sktree, &fd, cmpforsearch);
|
2002-10-31 19:49:52 +00:00
|
|
|
if (!s)
|
2019-09-08 19:29:00 +00:00
|
|
|
return; /* boggle */
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2019-01-22 18:25:54 +00:00
|
|
|
noise_ultralight(NOISE_SOURCE_IOID, fd);
|
2002-10-31 19:49:52 +00:00
|
|
|
|
|
|
|
|
switch (event) {
|
2019-02-07 18:13:56 +00:00
|
|
|
case SELECT_X: /* exceptional */
|
2019-09-08 19:29:00 +00:00
|
|
|
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);
|
|
|
|
|
noise_ultralight(NOISE_SOURCE_IOLEN, ret);
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
if (ret == 0) {
|
|
|
|
|
plug_closing_error(s->plug, "Internal networking trouble");
|
|
|
|
|
} else if (ret < 0) {
|
|
|
|
|
plug_closing_errno(s->plug, errno);
|
2019-09-08 19:29:00 +00:00
|
|
|
} else {
|
2005-01-16 14:29:34 +00: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;
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
plug_receive(s->plug, 2, buf, ret);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we reach here, this is an oobinline socket, which
|
|
|
|
|
* means we should set s->oobpending and then deal with it
|
|
|
|
|
* when we get called for the readability event (which
|
|
|
|
|
* should also occur).
|
|
|
|
|
*/
|
|
|
|
|
s->oobpending = true;
|
2002-11-01 13:36:48 +00:00
|
|
|
break;
|
2019-02-07 18:13:56 +00:00
|
|
|
case SELECT_R: /* readable; also acceptance */
|
2019-09-08 19:29:00 +00:00
|
|
|
if (s->listener) {
|
|
|
|
|
/*
|
|
|
|
|
* On a listening socket, the readability event means a
|
|
|
|
|
* connection is ready to be accepted.
|
|
|
|
|
*/
|
|
|
|
|
union sockaddr_union su;
|
|
|
|
|
socklen_t addrlen = sizeof(su);
|
2013-11-17 14:03:55 +00:00
|
|
|
accept_ctx_t actx;
|
2019-09-08 19:29:00 +00:00
|
|
|
int t; /* socket of connection */
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
memset(&su, 0, addrlen);
|
|
|
|
|
t = accept(s->s, &su.sa, &addrlen);
|
|
|
|
|
if (t < 0) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2002-10-31 19:49:52 +00:00
|
|
|
|
2013-07-19 18:10:02 +00:00
|
|
|
nonblock(t);
|
2013-11-17 14:03:55 +00:00
|
|
|
actx.i = t;
|
2008-02-21 09:18:24 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if ((!s->addr || s->addr->superfamily != UNIX) &&
|
2013-11-17 14:04:29 +00:00
|
|
|
s->localhost_only && !sockaddr_is_loopback(&su.sa)) {
|
2019-09-08 19:29:00 +00:00
|
|
|
close(t); /* someone let nonlocal through?! */
|
|
|
|
|
} else if (plug_accepting(s->plug, sk_net_accept, actx)) {
|
|
|
|
|
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 */
|
|
|
|
|
if (s->frozen)
|
|
|
|
|
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 19:23:19 +00:00
|
|
|
int atmark_from_ioctl;
|
2019-09-08 19:29:00 +00:00
|
|
|
if (ioctl(s->s, SIOCATMARK, &atmark_from_ioctl) == 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 19:23:19 +00:00
|
|
|
atmark = atmark_from_ioctl;
|
|
|
|
|
if (atmark)
|
|
|
|
|
s->oobpending = false; /* clear this indicator */
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
} else
|
|
|
|
|
atmark = true;
|
|
|
|
|
|
|
|
|
|
ret = recv(s->s, buf, s->oobpending ? 1 : sizeof(buf), 0);
|
|
|
|
|
noise_ultralight(NOISE_SOURCE_IOLEN, ret);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
if (errno == EWOULDBLOCK) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (ret < 0) {
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
plug_closing_errno(s->plug, errno);
|
2019-09-08 19:29:00 +00:00
|
|
|
} else if (0 == ret) {
|
2018-10-29 19:50:29 +00:00
|
|
|
s->incomingeof = true; /* stop trying to read now */
|
2011-09-13 11:44:03 +00:00
|
|
|
uxsel_tell(s);
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
plug_closing_normal(s->plug);
|
2019-09-08 19:29:00 +00:00
|
|
|
} else {
|
2005-01-16 14:29:34 +00: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;
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
plug_receive(s->plug, atmark ? 0 : 1, buf, ret);
|
|
|
|
|
}
|
|
|
|
|
break;
|
2019-02-07 18:13:56 +00:00
|
|
|
case SELECT_W: /* writable */
|
2019-09-08 19:29:00 +00:00
|
|
|
if (!s->connected) {
|
|
|
|
|
/*
|
|
|
|
|
* select/poll reports a socket as _writable_ when an
|
|
|
|
|
* asynchronous connect() attempt either completes or
|
|
|
|
|
* fails. So first we must find out which.
|
|
|
|
|
*/
|
2017-01-24 22:30:44 +00: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 18:10:23 +00:00
|
|
|
SockAddr thisaddr;
|
2017-01-24 22:30:44 +00:00
|
|
|
assert(s->addr);
|
2017-01-28 10:56:19 +00:00
|
|
|
|
|
|
|
|
thisaddr = sk_extractaddr_tmp(s->addr, &s->step);
|
2024-06-26 07:29:39 +00:00
|
|
|
plug_log(s->plug, &s->sock, PLUGLOG_CONNECT_FAILED,
|
2020-02-07 19:17:45 +00:00
|
|
|
&thisaddr, s->port, errmsg, err);
|
2017-01-28 10:56:19 +00:00
|
|
|
|
2017-01-24 22:30:44 +00:00
|
|
|
while (err && s->addr && sk_nextaddr(s->addr, &s->step)) {
|
|
|
|
|
err = try_connect(s);
|
|
|
|
|
}
|
2017-11-26 19:59:27 +00:00
|
|
|
if (err) {
|
Convenience wrappers on plug_closing().
Having a single plug_closing() function covering various kinds of
closure is reasonably convenient from the point of view of Plug
implementations, but it's annoying for callers, who all have to fill
in pointless NULL and 0 parameters in the cases where they're not
used.
Added some inline helper functions in network.h alongside the main
plug_closing() dispatch wrappers, so that each kind of connection
closure can present a separate API for the Socket side of the
interface, without complicating the vtable for the Plug side.
Also, added OS-specific extra helpers in the Unix and Windows
directories, which centralise the job of taking an OS error code (of
whatever kind) and translating it into its error message.
In passing, this removes the horrible ad-hoc made-up error codes in
proxy.h, which is OK, because nothing checked for them anyway, and
also I'm about to do an API change to plug_closing proper that removes
the need for them.
2021-11-06 13:25:42 +00:00
|
|
|
plug_closing_errno(s->plug, err);
|
2017-11-26 19:59:27 +00:00
|
|
|
return; /* socket is now presumably defunct */
|
|
|
|
|
}
|
2017-01-24 22:30:44 +00:00
|
|
|
if (!s->connected)
|
2016-05-30 21:52:30 +00:00
|
|
|
return; /* another async attempt in progress */
|
2020-02-07 19:18:50 +00:00
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* The connection attempt succeeded.
|
|
|
|
|
*/
|
|
|
|
|
SockAddr thisaddr = sk_extractaddr_tmp(s->addr, &s->step);
|
2024-06-26 07:29:39 +00:00
|
|
|
plug_log(s->plug, &s->sock, PLUGLOG_CONNECT_SUCCESS,
|
2020-02-07 19:18:50 +00:00
|
|
|
&thisaddr, s->port, NULL, 0);
|
2017-01-24 22:30:44 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we get here, we've managed to make a connection.
|
|
|
|
|
*/
|
|
|
|
|
if (s->addr) {
|
|
|
|
|
sk_addr_free(s->addr);
|
|
|
|
|
s->addr = NULL;
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
s->connected = true;
|
|
|
|
|
s->writable = true;
|
|
|
|
|
uxsel_tell(s);
|
|
|
|
|
} else {
|
|
|
|
|
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 19:23:19 +00:00
|
|
|
s->writable = true;
|
2019-09-08 19:29:00 +00: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;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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 18:10:23 +00:00
|
|
|
const char *sk_addr_error(SockAddr *addr)
|
2002-10-31 19:49:52 +00: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 18:10:23 +00:00
|
|
|
static const char *sk_net_socket_error(Socket *sock)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 19:49:52 +00: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 19:23:19 +00:00
|
|
|
static void sk_net_set_frozen(Socket *sock, bool is_frozen)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2002-10-31 19:49:52 +00:00
|
|
|
if (s->frozen == is_frozen)
|
2019-09-08 19:29:00 +00:00
|
|
|
return;
|
2002-10-31 19:49:52 +00:00
|
|
|
s->frozen = is_frozen;
|
2003-03-29 16:47:06 +00:00
|
|
|
uxsel_tell(s);
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2024-06-26 05:47:53 +00:00
|
|
|
static SocketEndpointInfo *sk_net_endpoint_info(Socket *sock, bool peer)
|
2015-05-18 12:57:45 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
2016-01-28 21:22:07 +00:00
|
|
|
union sockaddr_union addr;
|
2015-05-18 12:57:45 +00:00
|
|
|
socklen_t addrlen = sizeof(addr);
|
2016-01-28 21:22:07 +00:00
|
|
|
#ifndef NO_IPV6
|
2015-05-18 12:57:45 +00:00
|
|
|
char buf[INET6_ADDRSTRLEN];
|
2016-01-28 21:22:07 +00:00
|
|
|
#endif
|
2024-06-26 05:35:40 +00:00
|
|
|
SocketEndpointInfo *pi;
|
2015-05-18 12:57:45 +00:00
|
|
|
|
2024-06-26 05:47:53 +00:00
|
|
|
{
|
|
|
|
|
int retd = (peer ? getpeername(s->s, &addr.sa, &addrlen) :
|
|
|
|
|
getsockname(s->s, &addr.sa, &addrlen));
|
|
|
|
|
if (retd < 0)
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2018-10-18 19:06:42 +00:00
|
|
|
|
2024-06-26 05:35:40 +00:00
|
|
|
pi = snew(SocketEndpointInfo);
|
2018-10-18 19:06:42 +00:00
|
|
|
pi->addressfamily = ADDRTYPE_UNSPEC;
|
|
|
|
|
pi->addr_text = NULL;
|
|
|
|
|
pi->port = -1;
|
|
|
|
|
pi->log_text = NULL;
|
|
|
|
|
|
2016-01-28 21:22:07 +00:00
|
|
|
if (addr.storage.ss_family == AF_INET) {
|
2018-10-18 19:06:42 +00: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 12:57:45 +00:00
|
|
|
#ifndef NO_IPV6
|
2016-01-28 21:22:07 +00:00
|
|
|
} else if (addr.storage.ss_family == AF_INET6) {
|
2018-10-18 19:06:42 +00: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 12:57:45 +00:00
|
|
|
#endif
|
2018-10-18 19:06:42 +00:00
|
|
|
|
2016-01-28 21:22:07 +00:00
|
|
|
} else if (addr.storage.ss_family == AF_UNIX) {
|
2018-10-18 19:06:42 +00:00
|
|
|
pi->addressfamily = ADDRTYPE_LOCAL;
|
|
|
|
|
|
2015-05-18 12:57:45 +00:00
|
|
|
/*
|
|
|
|
|
* For Unix sockets, the source address is unlikely to be
|
2018-10-18 19:06:42 +00: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 12:57:45 +00: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 19:06:42 +00:00
|
|
|
pi->log_text = dupprintf("pid %d (%s:%s)", pid,
|
|
|
|
|
pw ? pw->pw_name : uidbuf,
|
|
|
|
|
gr ? gr->gr_name : gidbuf);
|
2015-05-18 12:57:45 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2018-10-18 19:06:42 +00:00
|
|
|
sfree(pi);
|
2015-05-18 12:57:45 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
2018-10-18 19:06:42 +00:00
|
|
|
|
|
|
|
|
return pi;
|
2015-05-18 12:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
Add a /proc/net magic authenticator.
This is a Linux-specific trick that I'm quite fond of: I've used it
before in 'agedu' and a lot of my unpublished personal scriptery.
Suppose you want to run a listening network server in such a way that
it can only accept connections from processes under your own control.
Often it's not convenient to do this by adding an authentication step
to the protocol itself (either because the password management gets
hairy or because the protocol is already well defined). The 'right'
answer is to switch from TCP to Unix-domain sockets, because then you
can use the file permissions on the path leading to the socket inode
to ensure that no other user id can connect to it - but that's often
inconvenient as well, because if any _client_ of the server is not
already prepared to speak AF_UNIX your control then you can only trick
it into connecting to an AF_UNIX socket instead of TCP by applying a
downstream patch or resorting to LD_PRELOAD shenanigans.
But on Linux, there's an alternative shenanigan available, in the form
of /proc/net/tcp (or tcp6), which lists every currently active TCP
endpoint known to the kernel, and for each one, lists an owning uid.
Listen on localhost only. Then, when a connection comes in, look up
the far end of it in that file and see if the owning uid is the right
one!
I've always vaguely wondered if there would be uses for this trick in
PuTTY. One potentially useful one might be to protect the listening
sockets created by local-to-remote port forwarding. But for the
moment, I'm only planning to use it for a less security-critical
purpose, which will appear in the next commit.
2019-03-31 08:24:17 +00:00
|
|
|
int sk_net_get_fd(Socket *sock)
|
|
|
|
|
{
|
|
|
|
|
/* This function is not fully general: it only works on NetSocket */
|
|
|
|
|
if (sock->vt != &NetSocket_sockvt)
|
|
|
|
|
return -1; /* failure */
|
|
|
|
|
NetSocket *s = container_of(sock, NetSocket, sock);
|
|
|
|
|
return s->s;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-27 08:29:33 +00:00
|
|
|
static void uxsel_tell(NetSocket *s)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
2003-03-29 16:47:06 +00:00
|
|
|
int rwx = 0;
|
2011-12-08 19:15:57 +00:00
|
|
|
if (!s->pending_error) {
|
|
|
|
|
if (s->listener) {
|
2019-02-07 18:13:56 +00:00
|
|
|
rwx |= SELECT_R; /* read == accept */
|
2011-12-08 19:15:57 +00:00
|
|
|
} else {
|
|
|
|
|
if (!s->connected)
|
2019-02-07 18:13:56 +00:00
|
|
|
rwx |= SELECT_W; /* write == connect */
|
2011-12-08 19:15:57 +00:00
|
|
|
if (s->connected && !s->frozen && !s->incomingeof)
|
2019-02-07 18:13:56 +00:00
|
|
|
rwx |= SELECT_R | SELECT_X;
|
2011-12-08 19:15:57 +00:00
|
|
|
if (bufchain_size(&s->output_data))
|
2019-02-07 18:13:56 +00:00
|
|
|
rwx |= SELECT_W;
|
2011-12-08 19:15:57 +00:00
|
|
|
}
|
2005-02-16 11:44:44 +00:00
|
|
|
}
|
2003-03-29 16:47:06 +00:00
|
|
|
uxsel_set(s->s, rwx, net_select_result);
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
|
|
|
|
|
2022-01-22 15:45:00 +00:00
|
|
|
int net_service_lookup(const char *service)
|
2002-10-31 19:49:52 +00:00
|
|
|
{
|
|
|
|
|
struct servent *se;
|
|
|
|
|
se = getservbyname(service, NULL);
|
|
|
|
|
if (se != NULL)
|
2019-09-08 19:29:00 +00:00
|
|
|
return ntohs(se->s_port);
|
2002-10-31 19:49:52 +00:00
|
|
|
else
|
2019-09-08 19:29:00 +00:00
|
|
|
return 0;
|
2002-10-31 19:49:52 +00:00
|
|
|
}
|
2004-05-31 14:01:52 +00: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 01:01:23 +00:00
|
|
|
char *get_hostname(void)
|
|
|
|
|
{
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
size_t size = 0;
|
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 01:01:23 +00:00
|
|
|
char *hostname = NULL;
|
|
|
|
|
do {
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
sgrowarray(hostname, size, size);
|
2019-09-08 19:29:00 +00:00
|
|
|
if ((gethostname(hostname, size) < 0) && (errno != ENAMETOOLONG)) {
|
|
|
|
|
sfree(hostname);
|
|
|
|
|
hostname = NULL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
} while (strlen(hostname) >= size-1);
|
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 01:01:23 +00:00
|
|
|
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 18:10:23 +00:00
|
|
|
SockAddr *platform_get_x11_unix_address(const char *sockpath, int displaynum)
|
2004-05-31 14:01:52 +00:00
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
SockAddr *addr = snew(SockAddr);
|
2004-05-31 14:01:52 +00:00
|
|
|
int n;
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
memset(addr, 0, sizeof *addr);
|
|
|
|
|
addr->superfamily = UNIX;
|
2008-05-28 19:23:57 +00:00
|
|
|
/*
|
2008-11-17 18:38:09 +00:00
|
|
|
* In special circumstances (notably Mac OS X Leopard), we'll
|
|
|
|
|
* have been passed an explicit Unix socket path.
|
2008-05-28 19:23:57 +00:00
|
|
|
*/
|
2008-11-17 18:38:09 +00:00
|
|
|
if (sockpath) {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
n = snprintf(addr->hostname, sizeof addr->hostname,
|
2019-09-08 19:29:00 +00:00
|
|
|
"%s", sockpath);
|
2008-05-28 19:23:57 +00:00
|
|
|
} else {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
n = snprintf(addr->hostname, sizeof addr->hostname,
|
2019-09-08 19:29:00 +00:00
|
|
|
"%s%d", X11_UNIX_PATH, displaynum);
|
2008-05-28 19:23:57 +00:00
|
|
|
}
|
2008-11-17 18:38:09 +00:00
|
|
|
|
|
|
|
|
if (n < 0)
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->error = "snprintf failed";
|
|
|
|
|
else if (n >= sizeof addr->hostname)
|
|
|
|
|
addr->error = "X11 UNIX name too long";
|
2008-11-17 18:38:09 +00:00
|
|
|
|
2005-01-16 14:29:34 +00:00
|
|
|
#ifndef NO_IPV6
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->ais = NULL;
|
2005-01-16 14:29:34 +00:00
|
|
|
#else
|
|
|
|
|
ret->addresses = NULL;
|
2008-11-08 16:45:45 +00:00
|
|
|
ret->naddresses = 0;
|
2005-01-16 14:29:34 +00:00
|
|
|
#endif
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->refcount = 1;
|
|
|
|
|
return addr;
|
2004-05-31 14:01:52 +00:00
|
|
|
}
|
2013-11-17 14:04:29 +00:00
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
SockAddr *unix_sock_addr(const char *path)
|
2013-11-17 14:04:29 +00:00
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
SockAddr *addr = snew(SockAddr);
|
2013-11-17 14:04:29 +00:00
|
|
|
int n;
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
memset(addr, 0, sizeof *addr);
|
|
|
|
|
addr->superfamily = UNIX;
|
|
|
|
|
n = snprintf(addr->hostname, sizeof addr->hostname, "%s", path);
|
2013-11-17 14:04:29 +00:00
|
|
|
|
|
|
|
|
if (n < 0)
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->error = "snprintf failed";
|
|
|
|
|
else if (n >= sizeof addr->hostname ||
|
2017-02-14 21:59:52 +00:00
|
|
|
n >= sizeof(((struct sockaddr_un *)0)->sun_path))
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->error = "socket pathname too long";
|
2013-11-17 14:04:29 +00:00
|
|
|
|
|
|
|
|
#ifndef NO_IPV6
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->ais = NULL;
|
2013-11-17 14:04:29 +00:00
|
|
|
#else
|
|
|
|
|
ret->addresses = NULL;
|
|
|
|
|
ret->naddresses = 0;
|
|
|
|
|
#endif
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
addr->refcount = 1;
|
|
|
|
|
return addr;
|
2013-11-17 14:04:29 +00:00
|
|
|
}
|
|
|
|
|
|
Get rid of lots of implicit pointer types.
All the main backend structures - Ssh, Telnet, Pty, Serial etc - now
describe structure types themselves rather than pointers to them. The
same goes for the codebase-wide trait types Socket and Plug, and the
supporting types SockAddr and Pinger.
All those things that were typedefed as pointers are older types; the
newer ones have the explicit * at the point of use, because that's
what I now seem to be preferring. But whichever one of those is
better, inconsistently using a mixture of the two styles is worse, so
let's make everything consistent.
A few types are still implicitly pointers, such as Bignum and some of
the GSSAPI types; generally this is either because they have to be
void *, or because they're typedefed differently on different
platforms and aren't always pointers at all. Can't be helped. But I've
got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
|
|
|
Socket *new_unix_listener(SockAddr *listenaddr, Plug *plug)
|
2013-11-17 14:04:29 +00:00
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
int fd;
|
2013-11-17 14:04:29 +00:00
|
|
|
union sockaddr_union u;
|
|
|
|
|
union sockaddr_union *addr;
|
|
|
|
|
int addrlen;
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
NetSocket *s;
|
2013-11-17 14:04:29 +00:00
|
|
|
int retcode;
|
|
|
|
|
|
|
|
|
|
/*
|
2018-05-27 08:29:33 +00:00
|
|
|
* Create NetSocket structure.
|
2013-11-17 14:04:29 +00:00
|
|
|
*/
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s = snew(NetSocket);
|
|
|
|
|
s->sock.vt = &NetSocket_sockvt;
|
|
|
|
|
s->error = NULL;
|
|
|
|
|
s->plug = plug;
|
|
|
|
|
bufchain_init(&s->output_data);
|
|
|
|
|
s->writable = false; /* to start with */
|
|
|
|
|
s->sending_oob = 0;
|
|
|
|
|
s->frozen = false;
|
|
|
|
|
s->localhost_only = true;
|
|
|
|
|
s->pending_error = 0;
|
|
|
|
|
s->parent = s->child = NULL;
|
|
|
|
|
s->oobpending = false;
|
|
|
|
|
s->outgoingeof = EOF_NO;
|
|
|
|
|
s->incomingeof = false;
|
|
|
|
|
s->listener = true;
|
|
|
|
|
s->addr = listenaddr;
|
|
|
|
|
s->s = -1;
|
2013-11-17 14:04:29 +00:00
|
|
|
|
|
|
|
|
assert(listenaddr->superfamily == UNIX);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Open socket.
|
|
|
|
|
*/
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
fd = socket(AF_UNIX, SOCK_STREAM, 0);
|
|
|
|
|
if (fd < 0) {
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2013-11-17 14:04:29 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
cloexec(fd);
|
2013-11-17 14:04:29 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->oobinline = false;
|
2013-11-17 14:04:29 +00:00
|
|
|
|
|
|
|
|
memset(&u, '\0', sizeof(u));
|
|
|
|
|
u.su.sun_family = AF_UNIX;
|
2018-09-26 13:20:25 +00:00
|
|
|
#if __GNUC__ >= 8
|
|
|
|
|
# pragma GCC diagnostic push
|
|
|
|
|
# pragma GCC diagnostic ignored "-Wstringop-truncation"
|
|
|
|
|
#endif // __GNUC__ >= 8
|
2013-11-17 14:04:29 +00:00
|
|
|
strncpy(u.su.sun_path, listenaddr->hostname, sizeof(u.su.sun_path)-1);
|
2018-09-26 13:20:25 +00:00
|
|
|
#if __GNUC__ >= 8
|
|
|
|
|
# pragma GCC diagnostic pop
|
|
|
|
|
#endif // __GNUC__ >= 8
|
2013-11-17 14:04:29 +00:00
|
|
|
addr = &u;
|
|
|
|
|
addrlen = sizeof(u.su);
|
|
|
|
|
|
|
|
|
|
if (unlink(u.su.sun_path) < 0 && errno != ENOENT) {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
close(fd);
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2013-11-17 14:04:29 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
retcode = bind(fd, &addr->sa, addrlen);
|
2013-11-17 14:04:29 +00:00
|
|
|
if (retcode < 0) {
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
close(fd);
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2013-11-17 14:04:29 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
if (listen(fd, SOMAXCONN) < 0) {
|
|
|
|
|
close(fd);
|
|
|
|
|
s->error = strerror(errno);
|
|
|
|
|
return &s->sock;
|
2013-11-17 14:04:29 +00:00
|
|
|
}
|
|
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
s->s = fd;
|
2013-11-17 14:04:29 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
uxsel_tell(s);
|
|
|
|
|
add234(sktree, s);
|
2013-11-17 14:04:29 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
return &s->sock;
|
2013-11-17 14:04:29 +00:00
|
|
|
}
|