| Message ID | 4AA1C086.5000607@hp.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Brian Haley <brian.haley@hp.com> Date: Fri, 04 Sep 2009 21:36:06 -0400 > Hi Marcel, > > Marcel Holtmann wrote: >> can we please add the err = -E... where it actually is needed and not >> stupidly go ahead and silence compiler warnings with err = 0. This has >> been posted before. > > Sorry, I don't remember it being posted before. If you look at the code > though, err is correctly initialized, gcc just can't figure it out. The > choices I see are either what I originally posted, using uninitialized_var(err), > or the patch below. It doesn't matter to me. uninitialized_var() would be absolutely wrong here, as then we'd return garbage if such a path were actually possible. Your original patch was fine and I'm going to apply it, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller wrote, On 09/05/2009 05:33 AM: > From: Brian Haley <brian.haley@hp.com> > Date: Fri, 04 Sep 2009 21:36:06 -0400 > >> Hi Marcel, >> >> Marcel Holtmann wrote: >>> can we please add the err = -E... where it actually is needed and not >>> stupidly go ahead and silence compiler warnings with err = 0. This has >>> been posted before. >> Sorry, I don't remember it being posted before. If you look at the code >> though, err is correctly initialized, gcc just can't figure it out. The >> choices I see are either what I originally posted, using uninitialized_var(err), >> or the patch below. It doesn't matter to me. > > uninitialized_var() would be absolutely wrong here, as then we'd > return garbage if such a path were actually possible. If the main "thesis" of the patch is: > From following the code 'err' is initialized, but set it to zero to > silence the warning. "we" should better be sure it "is initialized", so considering: "if such a path were actually possible" "would be absolutely wrong here"... Here is a link to the message which proved something else was possible at some moment in -next (I didn't check the current code yet): From: Stephen Rothwell <sfr@canb.auug.org.au> Subject: Re: [PATCH] Fix Warnings from net/netlink/genetlink.c Date: Wed, 12 Aug 2009 13:50:31 +1000 Archived-At: http://permalink.gmane.org/gmane.linux.kernel.next/8786 Jarek P. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jarek Poplawski <jarkao2@gmail.com> Date: Sat, 05 Sep 2009 09:52:40 +0200 > http://permalink.gmane.org/gmane.linux.kernel.next/8786 Right, and that was my thinking. So setting it to zero to begin with is the right thing to do. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 66f6ba0..8741036 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c @@ -177,6 +177,7 @@ int genl_register_mc_group(struct genl_family *family, struct net *net; rcu_read_lock(); + err = 0; for_each_net_rcu(net) { err = netlink_change_ngroups(net->genl_sock, mc_groups_longs * BITS_PER_LONG);