On Tue, 3 Oct 2023 17:50:13 +0100
Ferruh Yigit <ferruh.yi...@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.yi...@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 <step...@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.
