2011/4/15 Eric Blake <eblake@xxxxxxxxxx>:
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list