[PATCH v2] net/tap: resolve stringop-overflow with gcc 12 on ppc64le

[Stephen Hemminger]

On Wed, 7 Jun 2023 19:47:04 +0100
Ferruh Yigit <ferruh.yigit at amd.com> wrote:

> On 5/16/2023 10:55 AM, Ferruh Yigit wrote:
> > On 5/16/2023 2:28 AM, Stephen Hemminger wrote:  
> >> On Tue, 16 May 2023 00:35:56 +0100
> >> Ferruh Yigit <ferruh.yigit at amd.com> wrote:
> >>  
> >>> Yes only some scripts and possible applications that hotplug tap
> >>> interface with hardcoded parameters may impacted, don't know how big is
> >>> this amount but this ends up breaking something that was working before
> >>> upgrading DPDK for them.
> >>>
> >>> And I believe the motivation is weak to break the behavior.
> >>>
> >>> Won't it be better to update 'rte_ether_unformat_addr()' to accept more
> >>> flexible syntax, and use it? Is there any disadvantage of this approach?  
> >>
> >> It is already more flexible than the standard ether_aton().  
> > 
> > I mean to accept single chars, as 'tap' currently does, like "a:a:a:a:a:a".
> > 
> > Agree that impact of tap change is small, but if we can eliminate it
> > completely without any side affect, why not?
> > 
> > 
> > As accepting single char will be expanding 'rte_ether_unformat_addr()'
> > capability, it will be backward compatible, am I missing anything?

I did a little poking around. The single character format is actually non
standard.  It would be good to extend rte_unformat_ether_addr to allow a wider
range of formats including all those used by Windows, IEEE, and network vendors.