mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-12-13 11:58:30 +01:00
This is a follow up to commite7e5ddd2a. oss-fuzz found a case where performance was pathologically bad with a long `stop_chars` string. Since our inner loop in that case was iterating over `stop_chars` and comparing each of them to `buffer[i]`, we can use `memchr()` the opposite way round to in commite7e5ddd2ato speed that up, using `buffer[i]` as the needle in a `stop_chars` haystack. From some brief testing, this doesn’t impact on the performance of a more normal use case of having a short (<10 bytes long) `stop_chars`. I was slightly concerned that the function call overhead of calling out to `memchr()` would have an impact there, but apparently not. Signed-off-by: Philip Withnall <pwithnall@gnome.org> oss-fuzz#372994443
44 KiB
44 KiB