[libvirt] [PATCH] Remove hard dependency on DMI

Dave Allan dallan at redhat.com
Thu Mar 4 18:31:33 UTC 2010

On 03/03/2010 07:20 PM, Ed Swierk wrote:
> On Wed, Mar 3, 2010 at 2:57 PM, Dave Allan<dallan at redhat.com>  wrote:
>> Although I use goto a lot, I generally try to avoid multiple labels within a
>> function, just because I think it gets out of hand really quickly.  Although
>> it's a slightly more invasive patch, would you refactor the code to look
>> something like what I've attached?  I haven't even compile tested it as I'm
>> running late, but that's the idea.
> Is there a piece of code in libvirt that exemplifies the preferred
> error handling style? (http://libvirt.org/hacking.html doesn't cover
> this issue, as far as I can tell.) Just in the very small part of
> libvirt I've hacked on recently I've found a variety of styles,
> including

Agreed that we should add a statement to the hacking guide.  My 
preferences are as follows.

> - pair every allocation with a goto label that frees the allocation
> and all the earlier ones, and goto the appropriate label on error

I like Robert Love's description of this style at the very end of the 
thread at:


I like this style, but my impression is that generally the libvirt 
community prefers to have a single label that frees everything, perhaps 
conditionally on error, unless it's absolutely necessary to have 
multiple labels.

I reworked udevSetupSystemDev into this style (which also fixes the bug 
you pointed out that it didn't properly free resources on error).  The 
patch also makes failure to find DMI data non-fatal.

> - don't use goto at all, and on error, do the necessary frees and
> return -1, with each error case having to do one more free

I find this style troublesome to maintain, as any additional allocations 
require modifications to each error case.

> - a combination of the above, with each error case doing the necessary
> frees, but using goto out more or less as an alias for return -1

Again, I think duplicating the frees in each error case is less 
maintainable than having them in on place.

> - none of the above, not bothering to free anything when an allocation
> fails (see udevSetupSystemDev for an example)

Failure to cleanup is a bug.  Please send mail (and, even better, 
patches) about any other instances you find.

> There are probably arguments to be made for each of these styles, but
> it would be helpful to know which of them is preferred when writing
> new code or refactoring existing code.
> That said, I'll gladly refactor my patch towards the preferred style.
> --Ed

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Free-resources-on-error-in-udev-startup.patch
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100304/3f5a0102/attachment-0001.ksh>

More information about the libvir-list mailing list