Re: [dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, Dec 18, 2014 at 01:51:13PM +0000, Qiu, Michael wrote:
> On 2014/12/18 19:26, Neil Horman wrote:
> > On Wed, Dec 17, 2014 at 11:20:26PM +0100, Thomas Monjalon wrote:
> >> Hi Neil,
> >>
> >> 2014-12-17 12:03, Neil Horman:
> >>> Back in:
> >>>
> >>> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> >>> Author: Alan Carew <alan.carew@intel.com>
> >>> Date:   Fri Dec 5 15:19:07 2014 +0100
> >>>
> >>>     cmdline: fix overflow on bsd
> >>>
> >>> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  This
> >>> patch makes the needed correction to avoid a build break
> >>>
> >>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >>> CC: Thomas Monjalon <thomas.monjalon@6wind.com>
> >> What is the meaning of CC here?
> >>
> > CC is a tag that git send-email understands.  As it implies it cc's the post to
> > the indicated email, and records that fact in the body of the commit.
> 
> But if you use --cc in git send-email will be a good choice. CC list is
> useless for patch it self, but here it will exist in commit log(although
> this style can also be seen in linux kernel)
Yes, its good to have a record of who was CCed on a patch for archival purposes,
so you can get an idea of who participated (or was expected to participate in a
review)

Neil

> 
> Thanks,
> Michael
> >>> --- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> >>> +++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> >>> @@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
> >>>  		if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
> >>>  				sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
> >>>  			if (cmdline_parse_etheraddr(NULL,
> >>> -							pair[1],
> >>> -							&dict->addr) < 0) {
> >>> +						    pair[1],
> >>> +						    &dict->addr,
> >>> +						    sizeof(struct ether_addr)) < 0) {
> >> Why not sizeof(dict->addr)?
> >>
> > Because addr is a struct ether_addr, and I always get confused when doing sizeof
> > on pointer variables, so I find it more clear to specify the type exactly.  I'm
> > not bound to it though so if you like I can change it, though given its release
> > day, I figure you want to fix this build break asap.
> > Neil
> >
> >> -- 
> >> Thomas
> >>
> 
>