2011/4/15 Eric Blake <eblake(a)redhat.com>:
On 04/15/2011 03:01 PM, Matthias Bolte wrote:
>> + str = phypExecBuffer(session, buf, &ret, conn, true);
>> + if (!str || ret) {
>> + VIR_FREE(str);
>> + return -1;
>> + }
>> + ret = virStrToLong_i(str, NULL, 10, result);
>
> You made the parsing stricter by passing NULL as second argument to
> virStrToLong_i. I don't expect it but this might be possible that this
> breaks the behavior of the driver.
That was an intentional decision of mine (I guess I should have
documented it better), since the rest of the code was getting the
character after the parsed integer but doing nothing with it. In most
cases, it was like the code _expected_ a newline after the integer (such
as the output of a sed -c run, where that holds true), but wasn't
enforcing that expectation.
Should I modify the commit message and push with the newer strict
behavior, or modify the code to keep the older relaxed behavior (but
this time add a VIR_WARN if garbage is found after the parse)?
See my other mail in this thread for a detailed analysis.
Yes, lets stick to the relaxed parsing and add a VIR_WARN.
Matthias