[PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing

[walter harms]

Am 05.02.2018 11:24, schrieb Giuseppe Bilotta:
> On Mon, Feb 5, 2018 at 10:44 AM, walter harms <wharms at bfs.de> wrote:
>>
>> Am 05.02.2018 02:47, schrieb Giuseppe Bilotta:
>>>       {
>>>           double  sx, sy;
>>> +         char junk;
>>>           if (!config_output) argerr ("%s must be used after --output\n", argv[i]);
>>>           if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
>>> -         if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
>>> +         if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
>>>           {
>>> -             if (sscanf (argv[i], "%lf", &sx) != 1)
>>> +             if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
>>>                   argerr ("failed to parse '%s' as a scaling factor\n", argv[i]);
>>>               sy = sx;
>>>           }
>>
>> can the scanf be converted to strtod ? there you get an endpointer by default.
> 
> I'm not a big fan of strtod because with it it's impossible to know if
> a conversion actually happened. xrandr --scale '  ' would actually be
> accepted (resulting in a scale value of 0), while the scanf catches
> it. For the same reason I use two sscanf instead of a single one
> (because that wouldn't be able to catch something like xrandr --scale
> 1j).
> 
> Of course there's also to be said that we could reject a scale factor
> of 0, regardless of whether it comes from a correct parsing of the
> string '0.0' or from the parse of an empty string (but of course then
> we couldn't customize the error message to differentiate between
> “incorrect parse” and “value out of range”).
> 

Ok, i understand. My guess is that a scale factor of 0 would be rejected
or interessting things will happen ....

re,
 wh