1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
putty-source/unix/sftp.c

583 lines
12 KiB
C
Raw Permalink Normal View History

/*
* sftp.c: the Unix-specific parts of PSFTP and PSCP.
*/
#include <sys/time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <dirent.h>
#include <unistd.h>
#include <utime.h>
#include <errno.h>
#include <assert.h>
#include "putty.h"
#include "ssh.h"
#include "psftp.h"
#if HAVE_GLOB_H
#include <glob.h>
#endif
char *x_get_default(const char *key)
{
return NULL; /* this is a stub */
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
void platform_get_x11_auth(struct X11Display *display, Conf *conf)
{
/* Do nothing, therefore no auth. */
}
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
const bool platform_uses_x11_unix_by_default = true;
/*
* Default settings that are specific to PSFTP.
*/
char *platform_default_s(const char *name)
{
return NULL;
}
bool platform_default_b(const char *name, bool def)
{
return def;
}
int platform_default_i(const char *name, int def)
{
return def;
}
FontSpec *platform_default_fontspec(const char *name)
{
return fontspec_new_default();
}
Filename *platform_default_filename(const char *name)
{
if (!strcmp(name, "LogFileName"))
return filename_from_str("putty.log");
else
return filename_from_str("");
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult filexfer_get_userpass_input(Seat *seat, prompts_t *p)
{
Fix command-line password handling in Restart Session. When the user provides a password on the PuTTY command line, via -pw or -pwfile, the flag 'tried_once' inside cmdline_get_passwd_input() is intended to arrange that we only try sending that password once, and after we've sent it, we don't try again. But this plays badly with the 'Restart Session' operation. If the connection is lost and then restarted at user request, we _do_ want to send that password again! So this commit moves that static variable out into a small state structure held by the client of cmdline_get_passwd_input. Each client can decide how to manage that state itself. Clients that support 'Restart Session' - i.e. just GUI PuTTY itself - will initialise the state at the same time as instantiating the backend, so that every time the session is restarted, we return to (correctly) believing that we _haven't_ yet tried the password provided on the command line. But clients that don't support 'Restart Session' - i.e. Plink and file transfer tools - can do the same thing that cmdline.c was doing before: just keep the state in a static variable. This also means that the GUI login tools will now retain the command-line password in memory, whereas previously they'd have wiped it out once it was used. But the other tools will still wipe and free the password, because I've also added a 'bool restartable' flag to cmdline_get_passwd_input to let it know when it _is_ allowed to do that. In the GUI tools, I don't see any way to get round that, because if the session is restarted you _have_ to still have the password to use again. (And you can't infer that that will never happen from the CONF_close_on_exit setting, because that too could be changed in mid-session.) On the other hand, I think it's not all that worrying, because the use of either -pw or -pwfile means that a persistent copy of your password is *already* stored somewhere, so another one isn't too big a stretch. (Due to the change of -pw policy in 0.77, the effect of this bug was that an attempt to reconnect in a session set up this way would lead to "Configured password was not accepted". In 0.76, the failure mode was different: PuTTY would interactively prompt for the password, having wiped it out of memory after it was used the first time round.)
2022-05-18 12:04:56 +00:00
/* The file transfer tools don't support Restart Session, so we
* can just have a single static cmdline_get_passwd_input_state
* that's never reset */
static cmdline_get_passwd_input_state cmdline_state =
CMDLINE_GET_PASSWD_INPUT_STATE_INIT;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult spr;
Fix command-line password handling in Restart Session. When the user provides a password on the PuTTY command line, via -pw or -pwfile, the flag 'tried_once' inside cmdline_get_passwd_input() is intended to arrange that we only try sending that password once, and after we've sent it, we don't try again. But this plays badly with the 'Restart Session' operation. If the connection is lost and then restarted at user request, we _do_ want to send that password again! So this commit moves that static variable out into a small state structure held by the client of cmdline_get_passwd_input. Each client can decide how to manage that state itself. Clients that support 'Restart Session' - i.e. just GUI PuTTY itself - will initialise the state at the same time as instantiating the backend, so that every time the session is restarted, we return to (correctly) believing that we _haven't_ yet tried the password provided on the command line. But clients that don't support 'Restart Session' - i.e. Plink and file transfer tools - can do the same thing that cmdline.c was doing before: just keep the state in a static variable. This also means that the GUI login tools will now retain the command-line password in memory, whereas previously they'd have wiped it out once it was used. But the other tools will still wipe and free the password, because I've also added a 'bool restartable' flag to cmdline_get_passwd_input to let it know when it _is_ allowed to do that. In the GUI tools, I don't see any way to get round that, because if the session is restarted you _have_ to still have the password to use again. (And you can't infer that that will never happen from the CONF_close_on_exit setting, because that too could be changed in mid-session.) On the other hand, I think it's not all that worrying, because the use of either -pw or -pwfile means that a persistent copy of your password is *already* stored somewhere, so another one isn't too big a stretch. (Due to the change of -pw policy in 0.77, the effect of this bug was that an attempt to reconnect in a session set up this way would lead to "Configured password was not accepted". In 0.76, the failure mode was different: PuTTY would interactively prompt for the password, having wiped it out of memory after it was used the first time round.)
2022-05-18 12:04:56 +00:00
spr = cmdline_get_passwd_input(p, &cmdline_state, false);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
if (spr.kind == SPRK_INCOMPLETE)
spr = console_get_userpass_input(p);
return spr;
}
/*
* Set local current directory. Returns NULL on success, or else an
* error message which must be freed after printing.
*/
char *psftp_lcd(char *dir)
{
if (chdir(dir) < 0)
return dupprintf("%s: chdir: %s", dir, strerror(errno));
else
return NULL;
}
/*
* Get local current directory. Returns a string which must be
* freed.
*/
char *psftp_getcwd(void)
{
char *buffer, *ret;
size_t size = 256;
buffer = snewn(size, char);
while (1) {
ret = getcwd(buffer, size);
if (ret != NULL)
return ret;
if (errno != ERANGE) {
sfree(buffer);
return dupprintf("[cwd unavailable: %s]", strerror(errno));
}
/*
* Otherwise, ERANGE was returned, meaning the buffer
* wasn't big enough.
*/
sgrowarray(buffer, size, size);
}
}
struct RFile {
int fd;
};
RFile *open_existing_file(const char *name, uint64_t *size,
unsigned long *mtime, unsigned long *atime,
long *perms)
{
int fd;
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
RFile *f;
fd = open(name, O_RDONLY);
if (fd < 0)
return NULL;
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
f = snew(RFile);
f->fd = fd;
if (size || mtime || atime || perms) {
struct stat statbuf;
if (fstat(fd, &statbuf) < 0) {
fprintf(stderr, "%s: stat: %s\n", name, strerror(errno));
memset(&statbuf, 0, sizeof(statbuf));
}
if (size)
*size = statbuf.st_size;
if (mtime)
*mtime = statbuf.st_mtime;
if (atime)
*atime = statbuf.st_atime;
if (perms)
*perms = statbuf.st_mode;
}
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 f;
}
int read_from_file(RFile *f, void *buffer, int length)
{
return read(f->fd, buffer, length);
}
void close_rfile(RFile *f)
{
close(f->fd);
sfree(f);
}
struct WFile {
int fd;
char *name;
};
WFile *open_new_file(const char *name, long perms)
{
int fd;
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
WFile *f;
fd = open(name, O_CREAT | O_TRUNC | O_WRONLY,
(mode_t)(perms ? perms : 0666));
if (fd < 0)
return NULL;
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
f = snew(WFile);
f->fd = fd;
f->name = dupstr(name);
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 f;
}
WFile *open_existing_wfile(const char *name, uint64_t *size)
{
int fd;
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
WFile *f;
fd = open(name, O_APPEND | O_WRONLY);
if (fd < 0)
return NULL;
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
f = snew(WFile);
f->fd = fd;
f->name = dupstr(name);
if (size) {
struct stat statbuf;
if (fstat(fd, &statbuf) < 0) {
fprintf(stderr, "%s: stat: %s\n", name, strerror(errno));
memset(&statbuf, 0, sizeof(statbuf));
}
*size = statbuf.st_size;
}
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 f;
}
int write_to_file(WFile *f, void *buffer, int length)
{
char *p = (char *)buffer;
int so_far = 0;
/* Keep trying until we've really written as much as we can. */
while (length > 0) {
int ret = write(f->fd, p, length);
if (ret < 0)
return ret;
if (ret == 0)
break;
p += ret;
length -= ret;
so_far += ret;
}
return so_far;
}
void set_file_times(WFile *f, unsigned long mtime, unsigned long atime)
{
struct utimbuf ut;
ut.actime = atime;
ut.modtime = mtime;
utime(f->name, &ut);
}
/* Closes and frees the WFile */
void close_wfile(WFile *f)
{
close(f->fd);
sfree(f->name);
sfree(f);
}
/* Seek offset bytes through file, from whence, where whence is
FROM_START, FROM_CURRENT, or FROM_END */
int seek_file(WFile *f, uint64_t offset, int whence)
{
int lseek_whence;
switch (whence) {
case FROM_START:
lseek_whence = SEEK_SET;
break;
case FROM_CURRENT:
lseek_whence = SEEK_CUR;
break;
case FROM_END:
lseek_whence = SEEK_END;
break;
default:
return -1;
}
return lseek(f->fd, offset, lseek_whence) >= 0 ? 0 : -1;
}
uint64_t get_file_posn(WFile *f)
{
return lseek(f->fd, (off_t) 0, SEEK_CUR);
}
int file_type(const char *name)
{
struct stat statbuf;
if (stat(name, &statbuf) < 0) {
if (errno != ENOENT)
fprintf(stderr, "%s: stat: %s\n", name, strerror(errno));
return FILE_TYPE_NONEXISTENT;
}
if (S_ISREG(statbuf.st_mode))
return FILE_TYPE_FILE;
if (S_ISDIR(statbuf.st_mode))
return FILE_TYPE_DIRECTORY;
return FILE_TYPE_WEIRD;
}
struct DirHandle {
DIR *dir;
};
DirHandle *open_directory(const char *name, const char **errmsg)
{
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
DIR *dp = opendir(name);
if (!dp) {
*errmsg = strerror(errno);
return NULL;
}
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
DirHandle *dir = snew(DirHandle);
dir->dir = dp;
return dir;
}
char *read_filename(DirHandle *dir)
{
struct dirent *de;
do {
de = readdir(dir->dir);
if (de == NULL)
return NULL;
} while ((de->d_name[0] == '.' &&
(de->d_name[1] == '\0' ||
(de->d_name[1] == '.' && de->d_name[2] == '\0'))));
return dupstr(de->d_name);
}
void close_directory(DirHandle *dir)
{
closedir(dir->dir);
sfree(dir);
}
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 test_wildcard(const char *name, bool cmdline)
{
struct stat statbuf;
if (stat(name, &statbuf) == 0) {
return WCTYPE_FILENAME;
} else if (cmdline) {
/*
* On Unix, we never need to parse wildcards coming from
* the command line, because the shell will have expanded
* them into a filename list already.
*/
return WCTYPE_NONEXISTENT;
} else {
#if HAVE_GLOB_H
glob_t globbed;
int ret = WCTYPE_NONEXISTENT;
if (glob(name, GLOB_ERR, NULL, &globbed) == 0) {
if (globbed.gl_pathc > 0)
ret = WCTYPE_WILDCARD;
globfree(&globbed);
}
return ret;
#else
/* On a system without glob.h, we just have to return a
* failure code */
return WCTYPE_NONEXISTENT;
#endif
}
}
/*
* Actually return matching file names for a local wildcard.
*/
#if HAVE_GLOB_H
struct WildcardMatcher {
glob_t globbed;
int i;
};
WildcardMatcher *begin_wildcard_matching(const char *name) {
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
WildcardMatcher *dir = snew(WildcardMatcher);
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 (glob(name, 0, NULL, &dir->globbed) < 0) {
sfree(dir);
return NULL;
}
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
dir->i = 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
return dir;
}
char *wildcard_get_filename(WildcardMatcher *dir) {
if (dir->i < dir->globbed.gl_pathc) {
return dupstr(dir->globbed.gl_pathv[dir->i++]);
} else
return NULL;
}
void finish_wildcard_matching(WildcardMatcher *dir) {
globfree(&dir->globbed);
sfree(dir);
}
#else
WildcardMatcher *begin_wildcard_matching(const char *name)
{
return NULL;
}
char *wildcard_get_filename(WildcardMatcher *dir)
{
unreachable("Can't construct a valid WildcardMatcher without <glob.h>");
}
void finish_wildcard_matching(WildcardMatcher *dir)
{
unreachable("Can't construct a valid WildcardMatcher without <glob.h>");
}
#endif
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
char *stripslashes(const char *str, bool local)
{
char *p;
/*
* On Unix, we do the same thing regardless of the 'local'
* parameter.
*/
p = strrchr(str, '/');
if (p) str = p+1;
return (char *)str;
}
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 vet_filename(const char *name)
{
if (strchr(name, '/'))
return false;
if (name[0] == '.' && (!name[1] || (name[1] == '.' && !name[2])))
return false;
return true;
}
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 create_directory(const char *name)
{
return mkdir(name, 0777) == 0;
}
char *dir_file_cat(const char *dir, const char *file)
{
ptrlen dir_pl = ptrlen_from_asciz(dir);
return dupcat(
dir, ptrlen_endswith(dir_pl, PTRLEN_LITERAL("/"), NULL) ? "" : "/",
file);
}
/*
* Do a select() between all currently active network fds and
* optionally stdin, using cli_main_loop.
*/
struct ssh_sftp_mainloop_ctx {
bool include_stdin, no_fds_ok;
int toret;
};
static bool ssh_sftp_pw_setup(void *vctx, pollwrapper *pw)
{
struct ssh_sftp_mainloop_ctx *ctx = (struct ssh_sftp_mainloop_ctx *)vctx;
int fdstate, rwx;
if (!ctx->no_fds_ok && !toplevel_callback_pending() &&
first_fd(&fdstate, &rwx) < 0) {
ctx->toret = -1;
return false; /* terminate cli_main_loop */
}
if (ctx->include_stdin)
pollwrap_add_fd_rwx(pw, 0, SELECT_R);
return true;
}
static void ssh_sftp_pw_check(void *vctx, pollwrapper *pw)
{
struct ssh_sftp_mainloop_ctx *ctx = (struct ssh_sftp_mainloop_ctx *)vctx;
if (ctx->include_stdin && pollwrap_check_fd_rwx(pw, 0, SELECT_R))
ctx->toret = 1;
}
static bool ssh_sftp_mainloop_continue(void *vctx, bool found_any_fd,
bool ran_any_callback)
{
struct ssh_sftp_mainloop_ctx *ctx = (struct ssh_sftp_mainloop_ctx *)vctx;
if (ctx->toret != 0 || found_any_fd || ran_any_callback)
return false; /* finish the loop */
return true;
}
static int ssh_sftp_do_select(bool include_stdin, bool no_fds_ok)
{
struct ssh_sftp_mainloop_ctx ctx[1];
ctx->include_stdin = include_stdin;
ctx->no_fds_ok = no_fds_ok;
ctx->toret = 0;
cli_main_loop(ssh_sftp_pw_setup, ssh_sftp_pw_check,
ssh_sftp_mainloop_continue, ctx);
return ctx->toret;
}
/*
* Wait for some network data and process it.
*/
int ssh_sftp_loop_iteration(void)
{
return ssh_sftp_do_select(false, false);
}
/*
* Read a PSFTP command line from stdin.
*/
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
char *ssh_sftp_get_cmdline(const char *prompt, bool no_fds_ok)
{
char *buf;
size_t buflen, bufsize;
int ret;
fputs(prompt, stdout);
fflush(stdout);
buf = NULL;
buflen = bufsize = 0;
while (1) {
ret = ssh_sftp_do_select(true, no_fds_ok);
if (ret < 0) {
printf("connection died\n");
sfree(buf);
return NULL; /* woop woop */
}
if (ret > 0) {
sgrowarray(buf, bufsize, buflen);
ret = read(0, buf+buflen, 1);
if (ret < 0) {
perror("read");
sfree(buf);
return NULL;
}
if (ret == 0) {
/* eof on stdin; no error, but no answer either */
sfree(buf);
return NULL;
}
if (buf[buflen++] == '\n') {
/* we have a full line */
return buf;
}
}
}
}
void frontend_net_error_pending(void) {}
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
void platform_psftp_pre_conn_setup(LogPolicy *lp) {}
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
const bool buildinfo_gtk_relevant = false;
/*
* Main program: do platform-specific initialisation and then call
* psftp_main().
*/
int main(int argc, char *argv[])
{
uxsel_init();
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
CmdlineArgList *arglist = cmdline_arg_list_from_argv(argc, argv);
return psftp_main(arglist);
}