[libvirt] [PATCH 1/2] maint: avoid unwanted newline at end of diagnostic

[Chris Lalancette]

On 05/20/2010 05:18 AM, Jim Meyering wrote:
>>From 122b1e31fb33c092a53802b56a0f2f5586c95bd5 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyering at redhat.com>
> Date: Thu, 20 May 2010 11:12:17 +0200
> Subject: [PATCH 1/2] maint: remove unwanted newline at end of diagnostic
> 
> * src/xen/xend_internal.c (xenDaemonDomainDefineXML): Remove \n.
> * src/network/bridge_driver.c (networkAddMasqueradingIptablesRules):
> Likewise.
> ---
>  src/network/bridge_driver.c |    2 +-
>  src/xen/xend_internal.c     |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
> index 3b9b4f4..5d7ef19 100644
> --- a/src/network/bridge_driver.c
> +++ b/src/network/bridge_driver.c
> @@ -642,7 +642,7 @@ networkAddMasqueradingIptablesRules(struct network_driver *driver,
>                                              network->def->network,
>                                              network->def->forwardDev))) {
>          virReportSystemError(err,
> -                             _("failed to add iptables rule to enable masquerading to '%s'\n"),
> +                             _("failed to add iptables rule to enable masquerading to '%s'"),
>                               network->def->forwardDev ? network->def->forwardDev : NULL);
>          goto masqerr3;
>      }
> diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
> index ea5addd..a203a8d 100644
> --- a/src/xen/xend_internal.c
> +++ b/src/xen/xend_internal.c
> @@ -4731,7 +4731,7 @@ virDomainPtr xenDaemonDomainDefineXML(virConnectPtr conn, const char *xmlDesc) {
>      VIR_FREE(sexpr);
>      if (ret != 0) {
>          virXendError(VIR_ERR_XEN_CALL,
> -                     _("Failed to create inactive domain %s\n"), def->name);
> +                     _("Failed to create inactive domain %s"), def->name);
>          goto error;
>      }

ACK to this part, certainly.

I'm not sure a new syntax-check rule (which may have false positives) is worth it;
the fact that there are so few occurrences of the problem in the codebase seems
to say that it's not a huge problem, and I don't want to make sytnax-check fail
for people for bogus reasons.

-- 
Chris Lalancette