Re: [Qemu-devel] [PATCH v2 5/9] test-string-input-visitor: Add more tests

[Markus Armbruster]

David Hildenbrand <address@hidden> 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 <address@hidden>
>>>>> ---
>>>>>   tests/test-string-input-visitor.c | 41 +++++++++++++++++++++++++++++--
>>>>>   1 file changed, 39 insertions(+), 2 deletions(-)
>>>>>
>>>>
>>>> Reviewed-by: Eric Blake <address@hidden>
>>>
>>> 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."