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)?
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list