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

[Ferruh Yigit]

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?