This is a fix for a problem with ST that I found.
St relies on an incorrect assumption of how XmbLookupString function
behaves. When a composed input comes with a string that can not fit into
the buffer that was given to it — it doesn't fill it however much it
can, and then return exactly how much stuff was written, like most Unix
lib functions would; on the contrary, it returns the amount of data that
is available to be read and does not modify the contents of the buffer.
That causes a bug, which can be reproduced by assigning a large (longer
than 64 characters) string to some key-combination in your ~/.XCompose,
and then calling that key-combination when in ST. In most other programs
(e.g. Surf) the combination will be inserted in full. In ST, however,
random characters will pop up into the terminal, some of which may even
be control characters (such as ^C, ^D, ^Z) which leads to an Undefined
Behavior.
When a long composed string comes, the XmbLookupString returns it's
length to ST without writing anything into the buffer, then, without
checking anything, ST just chucks it in, even though the length of the
"data" is longer than the size of the buffer, passing both uninitized,
and unowned data to the subprocess.
The other function present (XLookupString) does not have the same
problem and behaves the way it is expected to behave, so it does not
need any fixes. XmbLookupString I fixed simply by calling once to get
the amount of data, and if it was too much for us, I reallocated the
buffer to fit that string and called it again. I have tested this
solution, and it works on my system, although I can not speak for all
systems and configurations.
---
Andy Gozas.
