In commit
1638409b22aef33d487863876ab214b949db4984, the number of
compose nodes was limited to 65535 to enable "future optimizations",
which apparently means slightly reduced memory usage due to fitting in
a uint16_t. At this time, it was mentioned that the author was not
aware of "any compose files which come close".
However, I'm one of the users that actually do require a larger number
of nodes for their compose file. Thus, use a uint32_t again and raise
the limit significantly.
const struct production *production)
{
unsigned lhs_pos = 0;
- uint16_t curr = darray_size(table->nodes) == 1 ? 0 : 1;
- uint16_t *pptr = NULL;
+ uint32_t curr = darray_size(table->nodes) == 1 ? 0 : 1;
+ uint32_t *pptr = NULL;
struct compose_node *node = NULL;
/* Warn before potentially going over the limit, discard silently after. */
* This is also sufficient for inferring the current status; see
* xkb_compose_state_get_status().
*/
- uint16_t prev_context;
- uint16_t context;
+ uint32_t prev_context;
+ uint32_t context;
};
XKB_EXPORT struct xkb_compose_state *
XKB_EXPORT enum xkb_compose_feed_result
xkb_compose_state_feed(struct xkb_compose_state *state, xkb_keysym_t keysym)
{
- uint16_t context;
+ uint32_t context;
const struct compose_node *node;
/*
* \0 is so offset 0 points to an empty string).
*/
-/* Fits in uint16_t, also a good idea to have some limit. */
-#define MAX_COMPOSE_NODES 65535
+/* 7 nodes for every potential Unicode character and then some should be
+ * enough for all purposes. */
+#define MAX_COMPOSE_NODES (1 << 23)
struct compose_node {
xkb_keysym_t keysym;
/* Offset into xkb_compose_table::nodes or 0. */
- uint16_t lokid;
+ uint32_t lokid;
/* Offset into xkb_compose_table::nodes or 0. */
- uint16_t hikid;
+ uint32_t hikid;
union {
struct {
uint32_t _pad:31;
bool is_leaf:1;
/* Offset into xkb_compose_table::nodes or 0. */
- uint16_t eqkid;
+ uint32_t eqkid;
} internal;
struct {
/* Offset into xkb_compose_table::utf8. */