Thanks - while gitlab is our preferred method, when that's not possible,
we prefer using the xorg-devel mailing list (cc'ed) instead of trying to
guess which individual developer to contact.
This bug has been previously reported, but no one has developed a good
fix yet - I don't know if many XKeysymToString callers keep references to
the returned pointers and would be broken if those pointers suddenly had a
different string or were invalid due to a realloc() call.
If they do, then perhaps a safer fix would be to keep a list of the
returned strings and reuse the pointer when the same keysym is seen again
instead of continuing to allocate new memory each time. The safest fix
would be to just have makekeys generate these values when building the
keysym tables, but that would increase the memory usage for those tables.
If not, and we decided overwriting the string each time was acceptable,
I'd just go with "static char s[10];" instead of malloc/realloc at all.
-alan-
On 8/20/22 01:56, Po Lu wrote:
Here's an untested fix for what I think is a leak in XKeysymToString.
I'm sorry if this is not the right way to reach an Xlib developer, but I
don't have an account on gitlab.freedesktop.org, and creating one is
difficult for me.
Thanks.
diff --git a/src/KeysymStr.c b/src/KeysymStr.c
index 8fe1bd64..a4f1c10a 100644
--- a/src/KeysymStr.c
+++ b/src/KeysymStr.c
@@ -120,13 +120,16 @@ char *XKeysymToString(KeySym ks)
}
if (ks >= 0x01000100 && ks <= 0x0110ffff) {
KeySym val = ks & 0xffffff;
- char *s;
+ static char *s;
int i;
if (val & 0xff0000)
i = 10;
else
i = 6;
- s = Xmalloc(i);
+ if (!s)
+ s = Xmalloc(i);
+ else
+ s = Xrealloc(s, i);
if (s == NULL)
return s;
i--;
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
