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 <[email protected]> >> --- >> 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.
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? -- Thanks, David / dhildenb
