David Hildenbrand <da...@redhat.com> writes: > On 15.11.18 18:13, Eric Blake wrote: >> On 11/15/18 8:04 AM, David Hildenbrand wrote: >>> Test that very big/small values are not accepted and that ranges with >>> only one element work. >>> >>> Rename expect4 to expect5, as we will be moving that to a separate ulist >>> test after the rework. >>> >>> Signed-off-by: David Hildenbrand <da...@redhat.com> >>> --- >>> tests/test-string-input-visitor.c | 22 ++++++++++++++++++++-- >>> 1 file changed, 20 insertions(+), 2 deletions(-) >>> >> >> I don't see a test for a range that wraps around (such as UINT_MAX-0); >> that's worth testing (whether it happens to work or is rejected as >> invalid). Do we require ranges to be ascending, or does 6-5 result in >> the sequence 5, 6? I also recall that our range code imposes a limit on >> the maximum elements present in a single range, in order to prevent >> denial-of-service attacks where a caller could request 0-INT_MAX to >> exhaust resources enumerating everything in the range; does our >> testsuite cover those limits? >> > Ranges have to be ascending and old code enforced that. New code still > enforces it. Wrapping ranges are AFAIC also not supported - not > ascending. I can add a test.
Good. > The limit is a good point. It is neither in the tests nor in the new > code. But now we finally have an explanation on the 65000-somewhat > thingy. I assume that we need such a limit? Yes, we do. We don't expect untrusted input here, but typo in the monitor (say 0--1 parsed as uint64_t 0, UINT_MAX) killing the VM by eating all memory is not a happy user experience.
