X11 allows keysyms to be specified in addition to strings.
We only support the strings. In the past, we ignored everything
after the string. Go back to doing that, but issue a warning
that we've ignored the keysym.
Keep string values in the table, and return them
from the check function. This commit temporarily
disables the table caching, since the cache format
does not handle string values yet.
Fixes: #186
Make it possible for gtk_compose_table_check to return
a string instead of just a single Unicode character.
Currently, we only ever return strings holding a single
character, still.
We're passing integers without validating their size, and newer GCC are
very cross about it, with warnings like:
warning: argument 1 range [18446744071562067968, 18446744073709551615]
exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
We should check we're not overflowing the allocation size, by limiting
the range of values we can use.
First of all, we need to use `gsize` instead of a random `int`, since we're
allocating data.
Additionally, we need to check that the multiplication that computes the
size of the allocation doesn't overflow the maximum value of a `gsize`.
Otherwise gcc complains when we use these as arguments to g_new() on
32bit architectures with:
../gtk/gtkcomposetable.c: In function ‘gtk_compose_table_list_add_array’:
/usr/include/glib-2.0/glib/gmem.h:217:10: warning: argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
__p = g_##func##_n (__n, __s); \
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmem.h:279:42: note: in expansion of macro ‘_G_NEW’
#define g_new0(struct_type, n_structs) _G_NEW (struct_type, n_structs, malloc0)
^~~~~~
../gtk/gtkcomposetable.c:851:22: note: in expansion of macro ‘g_new0’
gtk_compose_seqs = g_new0 (guint16, length);
^~~~~~
/usr/include/glib-2.0/glib/gmem.h:96:10: note: in a call to allocation function ‘g_malloc0_n’ declared here
gpointer g_malloc0_n (gsize n_blocks,
^~~~~~~~~~~
People might put all sorts of gunk in their .XCompose file, in
the hope that XLib makes sense of it. Even if we don't make sense
of it, we shouldn't abort, but instead ignore the lines we can't
understand. Pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1301254
