2003-03-05 22:07:40 +00:00
|
|
|
/*
|
|
|
|
|
* dialog.c - a reasonably platform-independent mechanism for
|
|
|
|
|
* describing dialog boxes.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
#include <limits.h>
|
|
|
|
|
#include <stdarg.h>
|
2003-03-06 12:41:39 +00:00
|
|
|
#include <stdlib.h>
|
2003-03-05 22:07:40 +00:00
|
|
|
|
|
|
|
|
#define DEFINE_INTORPTR_FNS
|
|
|
|
|
|
|
|
|
|
#include "putty.h"
|
|
|
|
|
#include "dialog.h"
|
|
|
|
|
|
2015-05-15 10:15:42 +00:00
|
|
|
int ctrl_path_elements(const char *path)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
int i = 1;
|
|
|
|
|
while (*path) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (*path == '/') i++;
|
|
|
|
|
path++;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Return the number of matching path elements at the starts of p1 and p2,
|
|
|
|
|
* or INT_MAX if the paths are identical. */
|
2015-05-15 10:15:42 +00:00
|
|
|
int ctrl_path_compare(const char *p1, const char *p2)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
while (*p1 || *p2) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if ((*p1 == '/' || *p1 == '\0') &&
|
|
|
|
|
(*p2 == '/' || *p2 == '\0'))
|
|
|
|
|
i++; /* a whole element matches, ooh */
|
|
|
|
|
if (*p1 != *p2)
|
|
|
|
|
return i; /* mismatch */
|
|
|
|
|
p1++, p2++;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
return INT_MAX; /* exact match */
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct controlbox *ctrl_new_box(void)
|
|
|
|
|
{
|
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
|
|
|
struct controlbox *b = snew(struct controlbox);
|
2003-03-05 22:07:40 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
b->nctrlsets = b->ctrlsetsize = 0;
|
|
|
|
|
b->ctrlsets = NULL;
|
|
|
|
|
b->nfrees = b->freesize = 0;
|
|
|
|
|
b->frees = NULL;
|
|
|
|
|
b->freefuncs = NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
return b;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ctrl_free_box(struct controlbox *b)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < b->nctrlsets; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
ctrl_free_set(b->ctrlsets[i]);
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
for (i = 0; i < b->nfrees; i++)
|
2019-09-08 19:29:00 +00:00
|
|
|
b->freefuncs[i](b->frees[i]);
|
2003-03-05 22:07:40 +00:00
|
|
|
sfree(b->ctrlsets);
|
|
|
|
|
sfree(b->frees);
|
2013-07-14 10:46:29 +00:00
|
|
|
sfree(b->freefuncs);
|
2003-03-05 22:07:40 +00:00
|
|
|
sfree(b);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ctrl_free_set(struct controlset *s)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
sfree(s->pathname);
|
|
|
|
|
sfree(s->boxname);
|
|
|
|
|
sfree(s->boxtitle);
|
|
|
|
|
for (i = 0; i < s->ncontrols; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
ctrl_free(s->ctrls[i]);
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
sfree(s->ctrls);
|
|
|
|
|
sfree(s);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Find the index of first controlset in a controlbox for a given
|
|
|
|
|
* path. If that path doesn't exist, return the index where it
|
|
|
|
|
* should be inserted.
|
|
|
|
|
*/
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static int ctrl_find_set(struct controlbox *b, const char *path, bool start)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
int i, last, thisone;
|
|
|
|
|
|
|
|
|
|
last = 0;
|
|
|
|
|
for (i = 0; i < b->nctrlsets; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
thisone = ctrl_path_compare(path, b->ctrlsets[i]->pathname);
|
|
|
|
|
/*
|
|
|
|
|
* If `start' is true and there exists a controlset with
|
|
|
|
|
* exactly the path we've been given, we should return the
|
|
|
|
|
* index of the first such controlset we find. Otherwise,
|
|
|
|
|
* we should return the index of the first entry in which
|
|
|
|
|
* _fewer_ path elements match than they did last time.
|
|
|
|
|
*/
|
|
|
|
|
if ((start && thisone == INT_MAX) || thisone < last)
|
|
|
|
|
return i;
|
|
|
|
|
last = thisone;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
return b->nctrlsets; /* insert at end */
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Find the index of next controlset in a controlbox for a given
|
|
|
|
|
* path, or -1 if no such controlset exists. If -1 is passed as
|
|
|
|
|
* input, finds the first.
|
|
|
|
|
*/
|
2015-05-15 10:15:42 +00:00
|
|
|
int ctrl_find_path(struct controlbox *b, const char *path, int index)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
if (index < 0)
|
2019-09-08 19:29:00 +00:00
|
|
|
index = ctrl_find_set(b, path, true);
|
2003-03-05 22:07:40 +00:00
|
|
|
else
|
2019-09-08 19:29:00 +00:00
|
|
|
index++;
|
2003-03-05 22:07:40 +00:00
|
|
|
|
|
|
|
|
if (index < b->nctrlsets && !strcmp(path, b->ctrlsets[index]->pathname))
|
2019-09-08 19:29:00 +00:00
|
|
|
return index;
|
2003-03-05 22:07:40 +00:00
|
|
|
else
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Set up a panel title. */
|
|
|
|
|
struct controlset *ctrl_settitle(struct controlbox *b,
|
2019-09-08 19:29:00 +00:00
|
|
|
const char *path, const char *title)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2019-09-08 19:29:00 +00:00
|
|
|
|
2003-03-29 16:14:26 +00:00
|
|
|
struct controlset *s = snew(struct controlset);
|
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 index = ctrl_find_set(b, path, true);
|
2003-03-05 22:07:40 +00:00
|
|
|
s->pathname = dupstr(path);
|
|
|
|
|
s->boxname = NULL;
|
|
|
|
|
s->boxtitle = dupstr(title);
|
|
|
|
|
s->ncontrols = s->ctrlsize = 0;
|
2019-09-08 19:29:00 +00:00
|
|
|
s->ncolumns = 0; /* this is a title! */
|
2003-03-05 22:07:40 +00:00
|
|
|
s->ctrls = NULL;
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
sgrowarray(b->ctrlsets, b->ctrlsetsize, b->nctrlsets);
|
2003-03-05 22:07:40 +00:00
|
|
|
if (index < b->nctrlsets)
|
2019-09-08 19:29:00 +00:00
|
|
|
memmove(&b->ctrlsets[index+1], &b->ctrlsets[index],
|
|
|
|
|
(b->nctrlsets-index) * sizeof(*b->ctrlsets));
|
2003-03-05 22:07:40 +00:00
|
|
|
b->ctrlsets[index] = s;
|
|
|
|
|
b->nctrlsets++;
|
|
|
|
|
return s;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Retrieve a pointer to a controlset, creating it if absent. */
|
2015-05-15 10:15:42 +00:00
|
|
|
struct controlset *ctrl_getset(struct controlbox *b, const char *path,
|
|
|
|
|
const char *name, const char *boxtitle)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
struct controlset *s;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
int index = ctrl_find_set(b, path, true);
|
2003-03-05 22:07:40 +00:00
|
|
|
while (index < b->nctrlsets &&
|
2019-09-08 19:29:00 +00:00
|
|
|
!strcmp(b->ctrlsets[index]->pathname, path)) {
|
|
|
|
|
if (b->ctrlsets[index]->boxname &&
|
|
|
|
|
!strcmp(b->ctrlsets[index]->boxname, name))
|
|
|
|
|
return b->ctrlsets[index];
|
|
|
|
|
index++;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
2003-03-29 16:14:26 +00:00
|
|
|
s = snew(struct controlset);
|
2003-03-05 22:07:40 +00:00
|
|
|
s->pathname = dupstr(path);
|
|
|
|
|
s->boxname = dupstr(name);
|
|
|
|
|
s->boxtitle = boxtitle ? dupstr(boxtitle) : NULL;
|
|
|
|
|
s->ncolumns = 1;
|
|
|
|
|
s->ncontrols = s->ctrlsize = 0;
|
|
|
|
|
s->ctrls = NULL;
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
sgrowarray(b->ctrlsets, b->ctrlsetsize, b->nctrlsets);
|
2003-03-05 22:07:40 +00:00
|
|
|
if (index < b->nctrlsets)
|
2019-09-08 19:29:00 +00:00
|
|
|
memmove(&b->ctrlsets[index+1], &b->ctrlsets[index],
|
|
|
|
|
(b->nctrlsets-index) * sizeof(*b->ctrlsets));
|
2003-03-05 22:07:40 +00:00
|
|
|
b->ctrlsets[index] = s;
|
|
|
|
|
b->nctrlsets++;
|
|
|
|
|
return s;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Allocate some private data in a controlbox. */
|
2013-07-14 10:46:29 +00:00
|
|
|
void *ctrl_alloc_with_free(struct controlbox *b, size_t size,
|
|
|
|
|
ctrl_freefn_t freefunc)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
void *p;
|
2003-03-29 16:14:26 +00:00
|
|
|
/*
|
|
|
|
|
* This is an internal allocation routine, so it's allowed to
|
|
|
|
|
* use smalloc directly.
|
|
|
|
|
*/
|
2003-03-05 22:07:40 +00:00
|
|
|
p = smalloc(size);
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
sgrowarray(b->frees, b->freesize, b->nfrees);
|
|
|
|
|
b->freefuncs = sresize(b->freefuncs, b->freesize, ctrl_freefn_t);
|
2013-07-14 10:46:29 +00:00
|
|
|
b->frees[b->nfrees] = p;
|
|
|
|
|
b->freefuncs[b->nfrees] = freefunc;
|
|
|
|
|
b->nfrees++;
|
2003-03-05 22:07:40 +00:00
|
|
|
return p;
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-14 10:46:29 +00:00
|
|
|
static void ctrl_default_free(void *p)
|
|
|
|
|
{
|
|
|
|
|
sfree(p);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void *ctrl_alloc(struct controlbox *b, size_t size)
|
|
|
|
|
{
|
|
|
|
|
return ctrl_alloc_with_free(b, size, ctrl_default_free);
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
static dlgcontrol *ctrl_new(struct controlset *s, int type,
|
2022-07-05 17:11:54 +00:00
|
|
|
HelpCtx helpctx, handler_fn handler,
|
2022-05-01 08:48:38 +00:00
|
|
|
intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = snew(dlgcontrol);
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
sgrowarray(s->ctrls, s->ctrlsize, s->ncontrols);
|
2003-03-05 22:07:40 +00:00
|
|
|
s->ctrls[s->ncontrols++] = c;
|
|
|
|
|
/*
|
|
|
|
|
* Fill in the standard fields.
|
|
|
|
|
*/
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->type = type;
|
|
|
|
|
c->delay_taborder = false;
|
|
|
|
|
c->column = COLUMN_FIELD(0, s->ncolumns);
|
|
|
|
|
c->helpctx = helpctx;
|
|
|
|
|
c->handler = handler;
|
|
|
|
|
c->context = context;
|
|
|
|
|
c->label = NULL;
|
|
|
|
|
c->align_next_to = NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* `ncolumns' is followed by that many percentages, as integers. */
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_columns(struct controlset *s, int ncolumns, ...)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-07-05 17:11:54 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_COLUMNS, NULL_HELPCTX, NULL, P(NULL));
|
2003-03-05 22:07:40 +00:00
|
|
|
assert(s->ncolumns == 1 || ncolumns == 1);
|
|
|
|
|
c->columns.ncols = ncolumns;
|
|
|
|
|
s->ncolumns = ncolumns;
|
|
|
|
|
if (ncolumns == 1) {
|
2019-09-08 19:29:00 +00:00
|
|
|
c->columns.percentages = NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
} else {
|
2019-09-08 19:29:00 +00:00
|
|
|
va_list ap;
|
|
|
|
|
int i;
|
|
|
|
|
c->columns.percentages = snewn(ncolumns, int);
|
|
|
|
|
va_start(ap, ncolumns);
|
|
|
|
|
for (i = 0; i < ncolumns; i++)
|
|
|
|
|
c->columns.percentages[i] = va_arg(ap, int);
|
|
|
|
|
va_end(ap);
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_editbox(struct controlset *s, const char *label,
|
|
|
|
|
char shortcut, int percentage,
|
2022-07-05 17:11:54 +00:00
|
|
|
HelpCtx helpctx, handler_fn handler,
|
2022-05-01 08:48:38 +00:00
|
|
|
intorptr context, intorptr context2)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_EDITBOX, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->editbox.shortcut = shortcut;
|
|
|
|
|
c->editbox.percentwidth = percentage;
|
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
|
|
|
c->editbox.password = false;
|
|
|
|
|
c->editbox.has_list = false;
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->context2 = context2;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_combobox(struct controlset *s, const char *label,
|
|
|
|
|
char shortcut, int percentage,
|
2022-07-05 17:11:54 +00:00
|
|
|
HelpCtx helpctx, handler_fn handler,
|
2022-05-01 08:48:38 +00:00
|
|
|
intorptr context, intorptr context2)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_EDITBOX, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->editbox.shortcut = shortcut;
|
|
|
|
|
c->editbox.percentwidth = percentage;
|
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
|
|
|
c->editbox.password = false;
|
|
|
|
|
c->editbox.has_list = true;
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->context2 = context2;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* `ncolumns' is followed by (alternately) radio button titles and
|
|
|
|
|
* intorptrs, until a NULL in place of a title string is seen. Each
|
|
|
|
|
* title is expected to be followed by a shortcut _iff_ `shortcut'
|
|
|
|
|
* is NO_SHORTCUT.
|
|
|
|
|
*/
|
2022-06-01 10:14:21 +00:00
|
|
|
dlgcontrol *ctrl_radiobuttons_fn(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, int ncolumns, HelpCtx helpctx,
|
2022-06-01 10:14:21 +00:00
|
|
|
handler_fn handler, intorptr context, ...)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
va_list ap;
|
|
|
|
|
int i;
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_RADIO, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->radio.shortcut = shortcut;
|
|
|
|
|
c->radio.ncolumns = ncolumns;
|
|
|
|
|
/*
|
|
|
|
|
* Initial pass along variable argument list to count the
|
|
|
|
|
* buttons.
|
|
|
|
|
*/
|
|
|
|
|
va_start(ap, context);
|
|
|
|
|
i = 0;
|
|
|
|
|
while (va_arg(ap, char *) != NULL) {
|
2019-09-08 19:29:00 +00:00
|
|
|
i++;
|
|
|
|
|
if (c->radio.shortcut == NO_SHORTCUT)
|
|
|
|
|
(void)va_arg(ap, int); /* char promotes to int in arg lists */
|
|
|
|
|
(void)va_arg(ap, intorptr);
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
va_end(ap);
|
|
|
|
|
c->radio.nbuttons = i;
|
|
|
|
|
if (c->radio.shortcut == NO_SHORTCUT)
|
2019-09-08 19:29:00 +00:00
|
|
|
c->radio.shortcuts = snewn(c->radio.nbuttons, char);
|
2003-03-05 22:07:40 +00:00
|
|
|
else
|
2019-09-08 19:29:00 +00:00
|
|
|
c->radio.shortcuts = NULL;
|
2003-03-29 16:14:26 +00:00
|
|
|
c->radio.buttons = snewn(c->radio.nbuttons, char *);
|
|
|
|
|
c->radio.buttondata = snewn(c->radio.nbuttons, intorptr);
|
2003-03-05 22:07:40 +00:00
|
|
|
/*
|
|
|
|
|
* Second pass along variable argument list to actually fill in
|
|
|
|
|
* the structure.
|
|
|
|
|
*/
|
|
|
|
|
va_start(ap, context);
|
|
|
|
|
for (i = 0; i < c->radio.nbuttons; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
c->radio.buttons[i] = dupstr(va_arg(ap, char *));
|
|
|
|
|
if (c->radio.shortcut == NO_SHORTCUT)
|
|
|
|
|
c->radio.shortcuts[i] = va_arg(ap, int);
|
|
|
|
|
/* char promotes to int in arg lists */
|
|
|
|
|
c->radio.buttondata[i] = va_arg(ap, intorptr);
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
va_end(ap);
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_pushbutton(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_BUTTON, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->button.shortcut = shortcut;
|
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
|
|
|
c->button.isdefault = false;
|
|
|
|
|
c->button.iscancel = false;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_listbox(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_LISTBOX, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->listbox.shortcut = shortcut;
|
2019-09-08 19:29:00 +00:00
|
|
|
c->listbox.height = 5; /* *shrug* a plausible default */
|
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
|
|
|
c->listbox.draglist = false;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->listbox.multisel = 0;
|
|
|
|
|
c->listbox.percentwidth = 100;
|
|
|
|
|
c->listbox.ncols = 0;
|
|
|
|
|
c->listbox.percentages = NULL;
|
2018-10-29 19:50:29 +00:00
|
|
|
c->listbox.hscroll = true;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_droplist(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, int percentage, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_LISTBOX, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->listbox.shortcut = shortcut;
|
2019-09-08 19:29:00 +00:00
|
|
|
c->listbox.height = 0; /* means it's a drop-down list */
|
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
|
|
|
c->listbox.draglist = false;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->listbox.multisel = 0;
|
|
|
|
|
c->listbox.percentwidth = percentage;
|
2003-05-12 13:41:41 +00:00
|
|
|
c->listbox.ncols = 0;
|
|
|
|
|
c->listbox.percentages = NULL;
|
2018-10-29 19:50:29 +00:00
|
|
|
c->listbox.hscroll = false;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_draglist(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_LISTBOX, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->listbox.shortcut = shortcut;
|
2019-09-08 19:29:00 +00:00
|
|
|
c->listbox.height = 5; /* *shrug* a plausible default */
|
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
|
|
|
c->listbox.draglist = true;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->listbox.multisel = 0;
|
|
|
|
|
c->listbox.percentwidth = 100;
|
2003-05-12 13:41:41 +00:00
|
|
|
c->listbox.ncols = 0;
|
|
|
|
|
c->listbox.percentages = NULL;
|
2018-10-29 19:50:29 +00:00
|
|
|
c->listbox.hscroll = false;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_filesel(struct controlset *s, const char *label,
|
2023-05-29 14:29:26 +00:00
|
|
|
char shortcut, FILESELECT_FILTER_TYPE filter,
|
|
|
|
|
bool write, const char *title, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_FILESELECT, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->fileselect.shortcut = shortcut;
|
|
|
|
|
c->fileselect.filter = filter;
|
|
|
|
|
c->fileselect.for_writing = write;
|
|
|
|
|
c->fileselect.title = dupstr(title);
|
2022-07-24 13:08:56 +00:00
|
|
|
c->fileselect.just_button = false;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_fontsel(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_FONTSELECT, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->fontselect.shortcut = shortcut;
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_tabdelay(struct controlset *s, dlgcontrol *ctrl)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-07-05 17:11:54 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_TABDELAY, NULL_HELPCTX, NULL, P(NULL));
|
2003-03-05 22:07:40 +00:00
|
|
|
c->tabdelay.ctrl = ctrl;
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_text(struct controlset *s, const char *text,
|
2022-07-05 17:11:54 +00:00
|
|
|
HelpCtx helpctx)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_TEXT, helpctx, NULL, P(NULL));
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = dupstr(text);
|
2022-05-07 07:23:38 +00:00
|
|
|
c->text.wrap = true;
|
2003-03-05 22:07:40 +00:00
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *ctrl_checkbox(struct controlset *s, const char *label,
|
2022-07-05 17:11:54 +00:00
|
|
|
char shortcut, HelpCtx helpctx,
|
2022-05-01 08:48:38 +00:00
|
|
|
handler_fn handler, intorptr context)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
2022-05-01 08:48:38 +00:00
|
|
|
dlgcontrol *c = ctrl_new(s, CTRL_CHECKBOX, helpctx, handler, context);
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
c->label = label ? dupstr(label) : NULL;
|
2003-03-05 22:07:40 +00:00
|
|
|
c->checkbox.shortcut = shortcut;
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-01 08:48:38 +00:00
|
|
|
void ctrl_free(dlgcontrol *ctrl)
|
2003-03-05 22:07:40 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
Restructure dlgcontrol as a struct with an anon union.
This gets rid of that awkward STANDARD_PREFIX system in which every
branch of the old 'union control' had to repeat all the generic
fields, and then call sites had to make an arbitrary decision about
which branch to access them through.
That was the best we could do before accepting C99 features in this
code base. But now we have anonymous unions, so we don't need to put
up with that nonsense any more!
'dlgcontrol' is now a struct rather than a union, and the generic
fields common to all control types are ordinary members of the struct,
so you don't have to refer to them as ctrl->generic.foo at all, just
ctrl->foo, which saves verbiage at the point of use.
The extra per-control fields are still held in structures named after
the control type, so you'll still say ctrl->listbox.height or
whatever. But now those structures are themselves members of an
anonymous union field following the generic fields, so those
sub-structures don't have to reiterate all the standard stuff too.
While I'm here, I've promoted 'context2' from an editbox-specific
field to a generic one (it just seems silly _not_ to allow any control
to have two context fields if it needs it). Also, I had to rename the
boolean field 'tabdelay' to avoid it clashing with the subsidiary
structure field 'tabdelay', now that the former isn't generic.tabdelay
any more.
2022-05-01 08:55:52 +00:00
|
|
|
sfree(ctrl->label);
|
|
|
|
|
switch (ctrl->type) {
|
2003-03-05 22:07:40 +00:00
|
|
|
case CTRL_RADIO:
|
2019-09-08 19:29:00 +00:00
|
|
|
for (i = 0; i < ctrl->radio.nbuttons; i++)
|
|
|
|
|
sfree(ctrl->radio.buttons[i]);
|
|
|
|
|
sfree(ctrl->radio.buttons);
|
|
|
|
|
sfree(ctrl->radio.shortcuts);
|
|
|
|
|
sfree(ctrl->radio.buttondata);
|
|
|
|
|
break;
|
2003-03-05 22:07:40 +00:00
|
|
|
case CTRL_COLUMNS:
|
2019-09-08 19:29:00 +00:00
|
|
|
sfree(ctrl->columns.percentages);
|
|
|
|
|
break;
|
2003-03-05 22:07:40 +00:00
|
|
|
case CTRL_LISTBOX:
|
2019-09-08 19:29:00 +00:00
|
|
|
sfree(ctrl->listbox.percentages);
|
|
|
|
|
break;
|
2003-03-05 22:07:40 +00:00
|
|
|
case CTRL_FILESELECT:
|
2019-09-08 19:29:00 +00:00
|
|
|
sfree(ctrl->fileselect.title);
|
|
|
|
|
break;
|
2003-03-05 22:07:40 +00:00
|
|
|
}
|
|
|
|
|
sfree(ctrl);
|
|
|
|
|
}
|