diff mbox series

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

Message ID 20231002183730.301163-2-stephen@networkplumber.org (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series rte_ether_unformat_addr changes |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Stephen Hemminger Oct. 2, 2023, 6:37 p.m. UTC 
  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>
---
 app/test/test_cmdline_etheraddr.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Comments

Ferruh Yigit Oct. 3, 2023, 10:47 a.m. UTC | #1 
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
Ferruh Yigit Oct. 3, 2023, 10:59 a.m. UTC | #2 
On 10/3/2023 11:47 AM, Ferruh Yigit 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
> 
> 

Ah, I guess it is taken as "XXXX:XXXX:XXXX" format, but number of digit
is not enforced, so "1:2:3" is a valid format, should we add this to API
documentation as example format? Or is this unintended side effect?
Stephen Hemminger Oct. 3, 2023, 4:36 p.m. UTC | #3 
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
Stephen Hemminger Oct. 3, 2023, 4:38 p.m. UTC | #4 
On Tue, 3 Oct 2023 11:59:04 +0100
Ferruh Yigit <ferruh.yigit@amd.com> wrote:

> Ah, I guess it is taken as "XXXX:XXXX:XXXX" format, but number of digit
> is not enforced, so "1:2:3" is a valid format, should we add this to API
> documentation as example format? Or is this unintended side effect?

By allowing leading zeros, it becomes allowed.
DPDK always allowed the non-standard 3 part format.
Looking around only old Cisco ACS used 3 part MAC format and it used
periods.

The API documentation should mention leading zeros are optional.
Ferruh Yigit Oct. 3, 2023, 4:50 p.m. UTC | #5 
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?
Stephen Hemminger Oct. 3, 2023, 5:18 p.m. UTC | #6 
On Tue, 3 Oct 2023 17:50:13 +0100
Ferruh Yigit <ferruh.yigit@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@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?
> 

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

Patch

diff --git a/app/test/test_cmdline_etheraddr.c b/app/test/test_cmdline_etheraddr.c
index 9691c32ba250..166c5716ba9b 100644
--- a/app/test/test_cmdline_etheraddr.c
+++ b/app/test/test_cmdline_etheraddr.c
@@ -20,7 +20,7 @@  struct ether_addr_str {
 };
 
 /* valid strings */
-const struct ether_addr_str ether_addr_valid_strs[] = {
+static const struct ether_addr_str ether_addr_valid_strs[] = {
 		{"01:23:45:67:89:AB", 0xAB8967452301ULL},
 		{"4567:89AB:CDEF", 0xEFCDAB896745ULL},
 };
@@ -30,7 +30,7 @@  const struct ether_addr_str ether_addr_valid_strs[] = {
  * end of token, which is either space chars, null char or
  * a hash sign.
  */
-const char * ether_addr_garbage_strs[] = {
+static const char * const ether_addr_garbage_strs[] = {
 		"00:11:22:33:44:55\0garbage",
 		"00:11:22:33:44:55#garbage",
 		"00:11:22:33:44:55 garbage",
@@ -46,14 +46,13 @@  const char * ether_addr_garbage_strs[] = {
 #define GARBAGE_ETHERADDR 0x554433221100ULL /* corresponding address */
 
 
-const char * ether_addr_invalid_strs[] = {
+static const char * const ether_addr_invalid_strs[] = {
 		/* valid chars, invalid syntax */
 		"0123:45:67:89:AB",
 		"01:23:4567:89:AB",
 		"01:23:45:67:89AB",
 		"012:345:678:9AB",
 		"01:23:45:67:89:ABC",
-		"01:23:45:67:89:A",
 		"01:23:45:67:89",
 		"01:23:45:67:89:AB:CD",
 		/* invalid chars, valid syntax */
@@ -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",
+		"01:23:45:67#:89:AB",
 		"random invalid text",
 		"random text",
 		"",