[libvirt] [PATCH] xenapi: fix the coding stype in xenapi_driver.c
Eric Blake
eblake at redhat.com
Tue Oct 22 14:37:22 UTC 2013
On 10/22/2013 03:05 PM, Hongwei Bi wrote:
>
> Signed-off-by: Hongwei Bi <hwbi2008 at gmail.com>
> ---
> src/xenapi/xenapi_driver.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c
> index 4b522c0..82af6f8 100644
> --- a/src/xenapi/xenapi_driver.c
> +++ b/src/xenapi/xenapi_driver.c
> @@ -437,7 +437,8 @@ xenapiConnectGetCapabilities(virConnectPtr conn)
> virCapsPtr caps = ((struct _xenapiPrivate *)(conn->privateData))->caps;
> if (caps) {
> char *xml = virCapabilitiesFormatXML(caps);
> - if (!xml) goto cleanup;
> + if (!xml)
> + goto cleanup;
Fails 'make syntax-check':
TAB_in_indentation
src/xenapi/xenapi_driver.c:441: goto cleanup;
maint.mk: indent with space, not TAB, in C, sh, html, py, syms and RNG
schemas
make: *** [sc_TAB_in_indentation] Error 1
Furthermore, there are more lines in this file with the same style
issue; such as several instances of:
if (vms) xen_vm_set_free(vms);
If you're going to submit style cleanup patches, make sure it is
correct, and it's best to convert the whole file at once rather than
just one instance. Even better would be adding a syntax check to
enforce the style after doing a cleanp. Until we have a series that ends
in enforcing a style, it's not worth the hassle of doing piecemeal
cleanup in isolation, because that merely pollutes the git history when
doing a 'git gui blame' (doing cleanup if you are about to patch other
aspects of the same method is okay, it's just cleanup in isolation that
has no real gain).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131022/8af97abe/attachment-0001.sig>
More information about the libvir-list
mailing list