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

671 lines
19 KiB
C
Raw Permalink Normal View History

Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
/*
* conf.c: implementation of the internal storage format used for
* the configuration of a PuTTY session.
*/
#include <stdio.h>
#include <stddef.h>
#include <assert.h>
#include "tree234.h"
#include "putty.h"
/*
* Configuration keys are primarily integers (big enum of all the
* different configurable options); some keys have string-designated
* subkeys, such as the list of environment variables (subkeys
* defined by the variable names); some have integer-designated
* subkeys (wordness, colours, preference lists).
*/
struct key {
int primary;
union {
int i;
char *s;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
} secondary;
};
/* Variant form of struct key which doesn't contain dynamic data, used
* for lookups. */
struct constkey {
int primary;
union {
int i;
const char *s;
} secondary;
};
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
struct value {
union {
bool boolval;
int intval;
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
struct {
char *str;
bool utf8;
} stringval;
Filename *fileval;
FontSpec *fontval;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
} u;
};
struct conf_entry {
struct key key;
struct value value;
};
struct conf_tag {
tree234 *tree;
};
/*
* Because 'struct key' is the first element in 'struct conf_entry',
* it's safe (guaranteed by the C standard) to cast arbitrarily back
* and forth between the two types. Therefore, we only need one
* comparison function, which can double as a main sort function for
* the tree (comparing two conf_entry structures with each other)
* and a search function (looking up an externally supplied key).
*/
static int conf_cmp(void *av, void *bv)
{
struct key *a = (struct key *)av;
struct key *b = (struct key *)bv;
if (a->primary < b->primary)
return -1;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
else if (a->primary > b->primary)
return +1;
switch (conf_key_info[a->primary].subkey_type) {
case CONF_TYPE_INT:
if (a->secondary.i < b->secondary.i)
return -1;
else if (a->secondary.i > b->secondary.i)
return +1;
return 0;
case CONF_TYPE_STR:
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_UTF8:
return strcmp(a->secondary.s, b->secondary.s);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_NONE:
return 0;
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
default:
unreachable("Unsupported subkey type");
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}
static int conf_cmp_constkey(void *av, void *bv)
{
struct key *a = (struct key *)av;
struct constkey *b = (struct constkey *)bv;
if (a->primary < b->primary)
return -1;
else if (a->primary > b->primary)
return +1;
switch (conf_key_info[a->primary].subkey_type) {
case CONF_TYPE_INT:
if (a->secondary.i < b->secondary.i)
return -1;
else if (a->secondary.i > b->secondary.i)
return +1;
return 0;
case CONF_TYPE_STR:
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_UTF8:
return strcmp(a->secondary.s, b->secondary.s);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_NONE:
return 0;
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
default:
unreachable("Unsupported subkey type");
}
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
/*
* Free any dynamic data items pointed to by a 'struct key'. We
* don't free the structure itself, since it's probably part of a
* larger allocated block.
*/
static void free_key(struct key *key)
{
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
if (conf_key_info[key->primary].subkey_type == CONF_TYPE_STR ||
conf_key_info[key->primary].subkey_type == CONF_TYPE_UTF8)
sfree(key->secondary.s);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
/*
* Copy a 'struct key' into another one, copying its dynamic data
* if necessary.
*/
static void copy_key(struct key *to, struct key *from)
{
to->primary = from->primary;
switch (conf_key_info[to->primary].subkey_type) {
case CONF_TYPE_INT:
to->secondary.i = from->secondary.i;
break;
case CONF_TYPE_STR:
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_UTF8:
to->secondary.s = dupstr(from->secondary.s);
break;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}
/*
* Free any dynamic data items pointed to by a 'struct value'. We
* don't free the value itself, since it's probably part of a larger
* allocated block.
*/
static void free_value(struct value *val, int type)
{
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
if (type == CONF_TYPE_STR || type == CONF_TYPE_UTF8 ||
type == CONF_TYPE_STR_AMBI)
sfree(val->u.stringval.str);
else if (type == CONF_TYPE_FILENAME)
filename_free(val->u.fileval);
else if (type == CONF_TYPE_FONT)
fontspec_free(val->u.fontval);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
/*
* Copy a 'struct value' into another one, copying its dynamic data
* if necessary.
*/
static void copy_value(struct value *to, struct value *from, int type)
{
switch (type) {
case CONF_TYPE_BOOL:
to->u.boolval = from->u.boolval;
break;
case CONF_TYPE_INT:
to->u.intval = from->u.intval;
break;
case CONF_TYPE_STR:
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_UTF8:
case CONF_TYPE_STR_AMBI:
to->u.stringval.str = dupstr(from->u.stringval.str);
to->u.stringval.utf8 = from->u.stringval.utf8;
break;
case CONF_TYPE_FILENAME:
to->u.fileval = filename_copy(from->u.fileval);
break;
case CONF_TYPE_FONT:
to->u.fontval = fontspec_copy(from->u.fontval);
break;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}
/*
* Free an entire 'struct conf_entry' and its dynamic data.
*/
static void free_entry(struct conf_entry *entry)
{
free_key(&entry->key);
free_value(&entry->value, conf_key_info[entry->key.primary].value_type);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
sfree(entry);
}
Conf *conf_new(void)
{
Conf *conf = snew(struct conf_tag);
conf->tree = newtree234(conf_cmp);
return conf;
}
void conf_clear(Conf *conf)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
struct conf_entry *entry;
while ((entry = delpos234(conf->tree, 0)) != NULL)
free_entry(entry);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
void conf_free(Conf *conf)
{
conf_clear(conf);
freetree234(conf->tree);
sfree(conf);
}
static void conf_insert(Conf *conf, struct conf_entry *entry)
{
struct conf_entry *oldentry = add234(conf->tree, entry);
if (oldentry && oldentry != entry) {
del234(conf->tree, oldentry);
free_entry(oldentry);
oldentry = add234(conf->tree, entry);
assert(oldentry == entry);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}
void conf_copy_into(Conf *newconf, Conf *oldconf)
{
struct conf_entry *entry, *entry2;
int i;
conf_clear(newconf);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
for (i = 0; (entry = index234(oldconf->tree, i)) != NULL; i++) {
entry2 = snew(struct conf_entry);
copy_key(&entry2->key, &entry->key);
copy_value(&entry2->value, &entry->value,
conf_key_info[entry->key.primary].value_type);
add234(newconf->tree, entry2);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}
Conf *conf_copy(Conf *oldconf)
{
Conf *newconf = conf_new();
conf_copy_into(newconf, oldconf);
return newconf;
}
bool conf_get_bool(Conf *conf, int primary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_BOOL);
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
return entry->value.u.boolval;
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int conf_get_int(Conf *conf, int primary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_INT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
return entry->value.u.intval;
}
int conf_get_int_int(Conf *conf, int primary, int secondary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_INT);
assert(conf_key_info[primary].value_type == CONF_TYPE_INT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
key.secondary.i = secondary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
return entry->value.u.intval;
}
char *conf_get_str(Conf *conf, int primary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
return entry->value.u.stringval.str;
}
char *conf_get_utf8(Conf *conf, int primary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_UTF8);
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
return entry->value.u.stringval.str;
}
char *conf_get_str_ambi(Conf *conf, int primary, bool *utf8)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR ||
conf_key_info[primary].value_type == CONF_TYPE_UTF8 ||
conf_key_info[primary].value_type == CONF_TYPE_STR_AMBI);
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
if (utf8)
*utf8 = entry->value.u.stringval.utf8;
return entry->value.u.stringval.str;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
char *conf_get_str_str_opt(Conf *conf, int primary, const char *secondary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_STR);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
key.secondary.s = (char *)secondary;
entry = find234(conf->tree, &key, NULL);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
return entry ? entry->value.u.stringval.str : NULL;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
char *conf_get_str_str(Conf *conf, int primary, const char *secondary)
{
char *ret = conf_get_str_str_opt(conf, primary, secondary);
assert(ret);
return ret;
}
char *conf_get_str_strs(Conf *conf, int primary,
char *subkeyin, char **subkeyout)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
struct constkey key;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_STR);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
if (subkeyin) {
key.secondary.s = subkeyin;
entry = findrel234(conf->tree, &key, NULL, REL234_GT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
} else {
key.secondary.s = "";
entry = findrel234(conf->tree, &key, conf_cmp_constkey, REL234_GE);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
if (!entry || entry->key.primary != primary)
return NULL;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
*subkeyout = entry->key.secondary.s;
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
return entry->value.u.stringval.str;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
char *conf_get_str_nthstrkey(Conf *conf, int primary, int n)
{
struct constkey key;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
struct conf_entry *entry;
int index;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_STR);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
key.secondary.s = "";
entry = findrelpos234(conf->tree, &key, conf_cmp_constkey,
REL234_GE, &index);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (!entry || entry->key.primary != primary)
return NULL;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry = index234(conf->tree, index + n);
if (!entry || entry->key.primary != primary)
return NULL;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
return entry->key.secondary.s;
}
Filename *conf_get_filename(Conf *conf, int primary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_FILENAME);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
return entry->value.u.fileval;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
FontSpec *conf_get_fontspec(Conf *conf, int primary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_FONT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
entry = find234(conf->tree, &key, NULL);
assert(entry);
return entry->value.u.fontval;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
void conf_set_bool(Conf *conf, int primary, bool value)
{
struct conf_entry *entry = snew(struct conf_entry);
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_BOOL);
entry->key.primary = primary;
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
entry->value.u.boolval = value;
conf_insert(conf, entry);
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
void conf_set_int(Conf *conf, int primary, int value)
{
struct conf_entry *entry = snew(struct conf_entry);
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_INT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry->key.primary = primary;
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
entry->value.u.intval = value;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_insert(conf, entry);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void conf_set_int_int(Conf *conf, int primary,
int secondary, int value)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
struct conf_entry *entry = snew(struct conf_entry);
assert(conf_key_info[primary].subkey_type == CONF_TYPE_INT);
assert(conf_key_info[primary].value_type == CONF_TYPE_INT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry->key.primary = primary;
entry->key.secondary.i = secondary;
entry->value.u.intval = value;
conf_insert(conf, entry);
}
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
bool conf_try_set_str(Conf *conf, int primary, const char *value)
{
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
if (conf_key_info[primary].value_type == CONF_TYPE_UTF8)
return false;
assert(conf_key_info[primary].value_type == CONF_TYPE_STR ||
conf_key_info[primary].value_type == CONF_TYPE_STR_AMBI);
struct conf_entry *entry = snew(struct conf_entry);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
entry->key.primary = primary;
entry->value.u.stringval.str = dupstr(value);
entry->value.u.stringval.utf8 = false;
conf_insert(conf, entry);
return true;
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
void conf_set_str(Conf *conf, int primary, const char *value)
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
{
bool success = conf_try_set_str(conf, primary, value);
assert(success && "conf_set_str on CONF_TYPE_UTF8");
}
bool conf_try_set_utf8(Conf *conf, int primary, const char *value)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
if (conf_key_info[primary].value_type == CONF_TYPE_STR)
return false;
assert(conf_key_info[primary].value_type == CONF_TYPE_UTF8 ||
conf_key_info[primary].value_type == CONF_TYPE_STR_AMBI);
struct conf_entry *entry = snew(struct conf_entry);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry->key.primary = primary;
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
entry->value.u.stringval.str = dupstr(value);
entry->value.u.stringval.utf8 = true;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_insert(conf, entry);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
return true;
}
void conf_set_utf8(Conf *conf, int primary, const char *value)
{
bool success = conf_try_set_utf8(conf, primary, value);
assert(success && "conf_set_utf8 on CONF_TYPE_STR");
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
void conf_set_str_str(Conf *conf, int primary, const char *secondary,
const char *value)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
struct conf_entry *entry = snew(struct conf_entry);
assert(conf_key_info[primary].subkey_type == CONF_TYPE_STR);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry->key.primary = primary;
entry->key.secondary.s = dupstr(secondary);
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
entry->value.u.stringval.str = dupstr(value);
entry->value.u.stringval.utf8 = false;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_insert(conf, entry);
}
void conf_del_str_str(Conf *conf, int primary, const char *secondary)
{
struct key key;
struct conf_entry *entry;
assert(conf_key_info[primary].subkey_type == CONF_TYPE_STR);
assert(conf_key_info[primary].value_type == CONF_TYPE_STR);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
key.primary = primary;
key.secondary.s = (char *)secondary;
entry = find234(conf->tree, &key, NULL);
if (entry) {
del234(conf->tree, entry);
free_entry(entry);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
void conf_set_filename(Conf *conf, int primary, const Filename *value)
{
struct conf_entry *entry = snew(struct conf_entry);
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_FILENAME);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry->key.primary = primary;
entry->value.u.fileval = filename_copy(value);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_insert(conf, entry);
}
void conf_set_fontspec(Conf *conf, int primary, const FontSpec *value)
{
struct conf_entry *entry = snew(struct conf_entry);
assert(conf_key_info[primary].subkey_type == CONF_TYPE_NONE);
assert(conf_key_info[primary].value_type == CONF_TYPE_FONT);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
entry->key.primary = primary;
entry->value.u.fontval = fontspec_copy(value);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_insert(conf, entry);
}
void conf_serialise(BinarySink *bs, Conf *conf)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
int i;
struct conf_entry *entry;
for (i = 0; (entry = index234(conf->tree, i)) != NULL; i++) {
put_uint32(bs, entry->key.primary);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
switch (conf_key_info[entry->key.primary].subkey_type) {
case CONF_TYPE_INT:
put_uint32(bs, entry->key.secondary.i);
break;
case CONF_TYPE_STR:
put_asciz(bs, entry->key.secondary.s);
break;
}
switch (conf_key_info[entry->key.primary].value_type) {
case CONF_TYPE_BOOL:
put_bool(bs, entry->value.u.boolval);
break;
case CONF_TYPE_INT:
put_uint32(bs, entry->value.u.intval);
break;
case CONF_TYPE_STR:
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
case CONF_TYPE_UTF8:
put_asciz(bs, entry->value.u.stringval.str);
break;
case CONF_TYPE_STR_AMBI:
put_asciz(bs, entry->value.u.stringval.str);
put_bool(bs, entry->value.u.stringval.utf8);
break;
case CONF_TYPE_FILENAME:
filename_serialise(bs, entry->value.u.fileval);
break;
case CONF_TYPE_FONT:
fontspec_serialise(bs, entry->value.u.fontval);
break;
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
put_uint32(bs, 0xFFFFFFFFU);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool conf_deserialise(Conf *conf, BinarySource *src)
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
struct conf_entry *entry;
unsigned primary;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
while (1) {
primary = get_uint32(src);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (get_err(src))
return false;
if (primary == 0xFFFFFFFFU)
return true;
if (primary >= N_CONFIG_OPTIONS)
return false;
entry = snew(struct conf_entry);
entry->key.primary = primary;
switch (conf_key_info[entry->key.primary].subkey_type) {
case CONF_TYPE_INT:
entry->key.secondary.i = toint(get_uint32(src));
break;
case CONF_TYPE_STR:
entry->key.secondary.s = dupstr(get_asciz(src));
break;
}
switch (conf_key_info[entry->key.primary].value_type) {
case CONF_TYPE_BOOL:
entry->value.u.boolval = get_bool(src);
break;
case CONF_TYPE_INT:
entry->value.u.intval = toint(get_uint32(src));
break;
case CONF_TYPE_STR:
Add two new string types to the Conf system. This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it.
2024-09-23 11:00:37 +00:00
entry->value.u.stringval.str = dupstr(get_asciz(src));
entry->value.u.stringval.utf8 = false;
break;
case CONF_TYPE_UTF8:
entry->value.u.stringval.str = dupstr(get_asciz(src));
entry->value.u.stringval.utf8 = true;
break;
case CONF_TYPE_STR_AMBI:
entry->value.u.stringval.str = dupstr(get_asciz(src));
entry->value.u.stringval.utf8 = get_bool(src);
break;
case CONF_TYPE_FILENAME:
entry->value.u.fileval = filename_deserialise(src);
break;
case CONF_TYPE_FONT:
entry->value.u.fontval = fontspec_deserialise(src);
break;
}
if (get_err(src)) {
free_entry(entry);
return false;
}
conf_insert(conf, entry);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
}