[libvirt] [PATCH v5 3/5] storage: add support for creating qcow2 images with extensions
Ján Tomko
jtomko at redhat.com
Mon Jun 24 06:48:44 UTC 2013
On 06/21/2013 08:40 PM, John Ferlan wrote:
> On 06/19/2013 11:24 AM, Ján Tomko wrote:
>> + if (features && format == VIR_STORAGE_FILE_QCOW2) {
>> + for (i = 0; i < VIR_STORAGE_FILE_FEATURE_LAST; i++) {
>> + ignore_value(virBitmapGetBit(features, i, &b));
>> + if (b) {
>> + switch (i) {
>> + case VIR_STORAGE_FILE_FEATURE_LAZY_REFCOUNTS:
>> + if (STREQ(compat, "0.10")) {
>> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
>> + _("Feature %s not supported with compat"
>> + " level %s"),
>> + virStorageFileFeatureTypeToString(i),
>> + compat);
>> + goto error;
>> + }
>> + break;
>
>
> With the patches for virNetDevSetupControlFull() my Coverity now runs;
> however, it's not very happy here...
>
> The pushed source code has:
> ...
> + case VIR_STORAGE_FILE_FEATURE_NONE:
> + case VIR_STORAGE_FILE_FEATURE_LAST:
> + ;
>
> But VIR_STORAGE_FILE_FEATURE_NONE = -1 and VIR_STORAGE_FILE_FEATURE_LAST
> is used as the loop ender and thus Coverity deems the code unreachable
> eliciting a "DEADCODE" error since 'i' could never be one or the other.
>
> I suppose the loop could change to:
>
> for (i = VIR_STORAGE_FILE_FEATURE_NONE;
> i <= VIR_STORAGE_FILE_FEATURE_LAST; i++)
>
> but that'd cause virBitmapGetBit() failure since 'i' cannot be negative
> in the call to it.
>
> John
>
I've pushed a fix for that:
commit 7a99eb912f8c99c23dc3e015a35224fc2c925459
Author: Ján Tomko <jtomko at redhat.com>
AuthorDate: 2013-06-24 08:35:59 +0200
Commit: Ján Tomko <jtomko at redhat.com>
CommitDate: 2013-06-24 08:44:46 +0200
Get rid of useless VIR_STORAGE_FILE_FEATURE_NONE
It's not used anywhere except for the switch in
virStorageBackendCreateQemuImgOpts, where leaving it in causes
a dead code coverity warning and omitting it breaks compilation
because of unhandled enum value.
Introduced by 6298f74.
git describe: v1.0.6-119-g7a99eb9
Jan
More information about the libvir-list
mailing list