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
