Vadim Zeitlin

Regression with autoconf tests for snprintf() in 10.0

Please demonstrate a crash. Sorry, no, I'm not prepared to invest possibly significant additional time for a very uncertain outcome (would you consider the problem serious if it only crashes on some ARM architecture when using specific gcc options? I have an inkling of an answer...), especially when I see absolutely no advantage to doing it rather than, you know, actually just spending 30 seconds on fixing the bug. My current belief is that this code will never trigger a crash but I could be wrong....

It is something that is of concern but not the degree of sky-falling-down that you are invoking. Would you really want anybody to quote you as saying that crashes in applications using Scintilla are "of concern but nothing really serious"? If so, you're a braver man than me, I wouldn't dare writing something like this publicly. No it doesn't. It reads and write 100 bytes. The last value of 'i' is 99. One of those bytes is from outside the buffer. You're totally correct, it reads 100 bytes and not...

Your potential security vulnerability doesn't make sense. Where is the DoS possibility? The code in question reads one char after the valid range And do you seriously think that reading beyond the allocated stack region is a normal and safe thing to do? and copies it into allocated memory. The string is still NUL-terminated before this char so is safe to read in WordList::InList. Perhaos you're not looking at the right code? This fragment: char s[100]; sc.GetCurrent(s, sizeof(s)); if (*s == ':')...

The important issue here is: have you tested the change? No, I didn't. To the best of my knowledge, there are no unit tests in Scintilla and I have no idea how to test this code interactively (I don't even know what is it supposed to do). Its all too easy to make a warning go away without actually doing the work required to ensure that the change is correct. Very true and I enthusiastically agree with this position in general. However in this particular case, the change is localized in a scope exactly...

I don't use MMIXAL neither, but this is a potential security vulnerability and really needs to be fixed. The best way to do it would be to just replace the entire loop/memmove with a single ++s as noted by the original reporter. This is a trivial change, please consider applying it just to stop people reporting it over and over again. TIA!

For the reference, libxml2 build withMinGW-w64-provided gcc 8 fails with the same error when -fno-omit-frame-pointer is used (but not without it).

I could try opening more tickets for the other functions, of course, although it's...