On Sun, Oct 23, 2022 at 04:18:42PM +0000, Andy Gozas wrote:
> 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.
>
Can you provide a minimal reproducable-case with your configuration for this issue?
It would help a lot in reviewing this issue.
> ---
> Andy Gozas.
>
--
Kind regards,
Hiltjo
Received on Sun Oct 23 2022 - 19:34:09 CEST