Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

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

On 10/3/2023 5:36 PM, Stephen Hemminger wrote:
> On Tue, 3 Oct 2023 11:47:51 +0100
> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> 
>> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
>>> Some of the ethernet address formats which were invalid will
>>> now become valid inputs when rte_ether_unformat_addr is modified
>>> to allow leading zeros.
>>>
>>> Also, make local variables static.
>>>
>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>   
>>
>> <...>
>>
>>> @@ -61,10 +60,8 @@ const char * ether_addr_invalid_strs[] = {
>>>  		"INVA:LIDC:HARS",
>>>  		/* misc */
>>>  		"01 23 45 67 89 AB",
>>> -		"01.23.45.67.89.AB",
>>>  		"01,23,45,67,89,AB",
>>> -		"01:23:45\0:67:89:AB",
>>> -		"01:23:45#:67:89:AB",
>>>  
>>
>> Why these two are valid now?
>>
>> And I guess second one is still not valid, but first one is parsed as
>> [1], is this expected?
>>
>> [1] 00:01:00:23:00:45
> 
> The code in cmdline converts the comment character # to a null byte.
> So both test are the same.
> 
> With new unformat, it allows a 3 part mac address with leading
> zeros.
> 	01:23:45 is equivalent to 0001:0023:0045
>

With 3 part MAC, omitting leading zeros looks confusing to me, because
that omitted part becomes an octet in MAC. Like:
01:23:45 being equivalent to 00:01:00:23:00:45

As 3 part MAC, and 6 part MAC has separate functions, does it makes
sense to require leading zeros in the 3 part MAC, what do you think?