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

[Ferruh Yigit <ferruh.yigit@amd.com>]

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@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?
> 

Hi David,

If API update is not planned, what do you think to just solve the build
error without changing functionality with a change something like below:

```
 -       (strlen(mac_byte) == strspn(mac_byte,
 -                       ETH_TAP_CMP_MAC_FMT))) {
 +       (strlen(mac_byte) == strspn(mac_byte, ETH_TAP_CMP_MAC_FMT)) &&
 +                       index < RTE_ETHER_ADDR_LEN) {

```