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

[Stephen Hemminger]

On Tue, 3 Oct 2023 17:50:13 +0100
Ferruh Yigit <ferruh.yigit at amd.com> wrote:

> On 10/3/2023 5:36 PM, Stephen Hemminger wrote:
> > On Tue, 3 Oct 2023 11:47:51 +0100
> > Ferruh Yigit <ferruh.yigit at 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 at 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?
> 

Right, 3 part MAC is only a legacy Cisco format, not used anywhere else.