]> git.kaiwu.me - haproxy.git/commit
BUG/MINOR: ist: make ist_find_range() accept non-zero min boundaries
authorWilly Tarreau <w@1wt.eu>
Wed, 4 Nov 2026 10:09:24 +0000 (11:09 +0100)
committerWilly Tarreau <w@1wt.eu>
Wed, 4 Nov 2026 21:45:32 +0000 (22:45 +0100)
commit40c6c6b20320fdf2d78083d8ae982db06b6e5e19
tree49bb62c066a18b79b454e02eb1ca86257424d393
parent22be7a72bd911cffb228a6686d3c2aeda62a9f24
BUG/MINOR: ist: make ist_find_range() accept non-zero min boundaries

The way ist_find_range() is currently constructed can make it miss the
lower bound. For example, checking "abcdefgh1jklmnop" against min='0'
and max='9' misses the '1' in the middle because the check only sees
bytes that are below (max-min), not those between min and max (the
min value is not subtracted before the comparison). It's OK in the
byte-at-a-time check however.

Let's just simplify the operation to make it work more like the
is_char8_below_opt() and is_char8_above_opt() functions. The idea
is to check (x-min) and (max-x) and combine them to check for the
carry. However there's still the case of testing that all bytes are
outside the interval (we don't want to miss one). The trick here
is to or the left term with the carry so that we keep the carry for
bytes outside and it only disappears when all bytes are ouside the
range. That way the loop stops when there's one carry, indicating
at least one byte within range, or one which had bit 7 previously
turned on (which was already mentioned as the exception), in which
case we finish one byte at a time. The only restriction is that
min <= max <= 0x7f, but that's already how the function was meant
to be used.

This can be backported, though it will not fix any bug because at
the moment, all callers pass 0 to the min value and are not affected.
include/import/ist.h