David Hildenbrand <da...@redhat.com> writes: > On 20.11.18 18:26, Eric Blake wrote: >> On 11/20/18 11:20 AM, Eric Blake wrote: >>> On 11/20/18 11:06 AM, Eric Blake wrote: >>>> On 11/20/18 3:25 AM, David Hildenbrand wrote: >>>>> Test that very big/small values are not accepted and that ranges with >>>>> only one element work. Also test that ranges are ascending and cannot >>>>> have more than 65536 elements. >>>>> >>>>> 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 | 41 +++++++++++++++++++++++++++++-- >>>>> 1 file changed, 39 insertions(+), 2 deletions(-) >>>>> >>>> >>>> Reviewed-by: Eric Blake <ebl...@redhat.com> >>> >>> Do we also want to test garbage strings like: >>> >>> "1-" (incomplete range) >>> "1X-2" (garbage suffix on first element) >>> "1-2X" (garbage suffix on second element) >>> >>> and/or >>> >>> "-2--1" (valid range of signed integers) >>> "-1--2" (questionable whether this is valid for the two largest unsigned >>> integers) >> >> Or even " 1- 2" (we permit leading whitespace for plain integers - do we >> also permit it in both sides of a range)? Also, if we permit whitespace >> after the range '-', should we permit it beforehand? >> >> These sorts of questions may be fine in followup patches. >> > > As always, you can never cover all cases during tests :) > > While these things surely make sense, I will not add them right now. As > you said, we can do that later. > > > Taking about spaces: > > I think spaces before the "-" are not supported before/after the rewrite > (I remember that strto.* does not skip over them). Spaces after the > space should be covered by strto* automatically (strto.* skips over > leading spaces).
qemu_strtol() & friends ignore leading whitespace, just like strtol() does. Trailing whitespace is handled like any other trailing characters: hard error when endptr is null, else make *endptr point to it. I'd expect whitespace to be accepted before either number of a range, but not between the first number and the '-'. Perhaps rejecting whitespace there would be the cleaner interface, but then we get to discuss backward compatibility, and I go "thanks, but no, thanks."
