lpm6: make IPv6 addresses immutable

  None of the public functions modify IPv6 address passed so their
parameters are made const.

Previously only lookup and add were updated to have addresses passed as
const so I'm adding this fixline.

Fixes: d82927d2f81d ("lpm6: make IPv6 address immutable")
Cc: stephen@networkplumber.org

Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
---
 lib/librte_lpm/rte_lpm6.c | 14 +++++++-------
 lib/librte_lpm/rte_lpm6.h | 13 +++++++------
 2 files changed, 14 insertions(+), 13 deletions(-)
  

Hi Andrze,

Adding const qualifier for bulk lookup leads to compilation problems 
(see http://c-faq.com/ansi/constmismatch.html)
Also I don't think it would be good for usability to make users 
explicitly cast to (const uint8_t **) when passing 'ips' argument. I'd 
suggest leaving lookup_bulk as is.

On 03/03/2020 12:53, Andrzej Ostruszka wrote:
> None of the public functions modify IPv6 address passed so their
> parameters are made const.
>
> Previously only lookup and add were updated to have addresses passed as
> const so I'm adding this fixline.
>
> Fixes: d82927d2f81d ("lpm6: make IPv6 address immutable")
> Cc: stephen@networkplumber.org
>
> Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
> ---
>   lib/librte_lpm/rte_lpm6.c | 14 +++++++-------
>   lib/librte_lpm/rte_lpm6.h | 13 +++++++------
>   2 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
> index d515600f1..6089217d6 100644
> --- a/lib/librte_lpm/rte_lpm6.c
> +++ b/lib/librte_lpm/rte_lpm6.c
> @@ -975,8 +975,8 @@ rte_lpm6_lookup(const struct rte_lpm6 *lpm, const uint8_t *ip,
>    */
>   int
>   rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
> -		uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> -		int32_t *next_hops, unsigned int n)
> +			  const uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> +			  int32_t *next_hops, unsigned int n)
>   {
>   	unsigned int i;
>   	const struct rte_lpm6_tbl_entry *tbl;
> @@ -1019,8 +1019,8 @@ rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
>    * Look for a rule in the high-level rules table
>    */
>   int
> -rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> -		uint32_t *next_hop)
> +rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth,
> +			 uint32_t *next_hop)
>   {
>   	uint8_t masked_ip[RTE_LPM6_IPV6_ADDR_SIZE];
>   
> @@ -1069,8 +1069,8 @@ rule_delete(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth)
>    */
>   int
>   rte_lpm6_delete_bulk_func(struct rte_lpm6 *lpm,
> -		uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE], uint8_t *depths,
> -		unsigned n)
> +			  const uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> +			  uint8_t *depths, unsigned n)
>   {
>   	uint8_t masked_ip[RTE_LPM6_IPV6_ADDR_SIZE];
>   	unsigned i;
> @@ -1290,7 +1290,7 @@ remove_tbl(struct rte_lpm6 *lpm, struct rte_lpm_tbl8_hdr *tbl_hdr,
>    * Deletes a rule
>    */
>   int
> -rte_lpm6_delete(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth)
> +rte_lpm6_delete(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth)
>   {
>   	uint8_t masked_ip[RTE_LPM6_IPV6_ADDR_SIZE];
>   	struct rte_lpm6_rule lsp_rule_obj;
> diff --git a/lib/librte_lpm/rte_lpm6.h b/lib/librte_lpm/rte_lpm6.h
> index 042991f8c..facf09b2b 100644
> --- a/lib/librte_lpm/rte_lpm6.h
> +++ b/lib/librte_lpm/rte_lpm6.h
> @@ -113,8 +113,8 @@ rte_lpm6_add(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth,
>    *   1 if the rule exists, 0 if it does not, a negative value on failure
>    */
>   int
> -rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> -		uint32_t *next_hop);
> +rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth,
> +			 uint32_t *next_hop);
>   
>   /**
>    * Delete a rule from the LPM table.
> @@ -129,7 +129,7 @@ rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
>    *   0 on success, negative value otherwise
>    */
>   int
> -rte_lpm6_delete(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth);
> +rte_lpm6_delete(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth);
>   
>   /**
>    * Delete a rule from the LPM table.
> @@ -147,7 +147,8 @@ rte_lpm6_delete(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth);
>    */
>   int
>   rte_lpm6_delete_bulk_func(struct rte_lpm6 *lpm,
> -		uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE], uint8_t *depths, unsigned n);
> +			  const uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> +			  uint8_t *depths, unsigned n);
>   
>   /**
>    * Delete all rules from the LPM table.
> @@ -191,8 +192,8 @@ rte_lpm6_lookup(const struct rte_lpm6 *lpm, const uint8_t *ip, uint32_t *next_ho
>    */
>   int
>   rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
> -		uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> -		int32_t *next_hops, unsigned int n);
> +			  const uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> +			  int32_t *next_hops, unsigned int n);
>   
>   #ifdef __cplusplus
>   }
  

On Mon, 9 Mar 2020 13:38:53 +0000
"Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:

> Hi Andrze,
> 
> Adding const qualifier for bulk lookup leads to compilation problems 
> (see http://c-faq.com/ansi/constmismatch.html)
> Also I don't think it would be good for usability to make users 
> explicitly cast to (const uint8_t **) when passing 'ips' argument. I'd 
> suggest leaving lookup_bulk as is.


Please give a more concrete example. There is no need for explicit cast
in current C.
  

On 09/03/2020 15:52, Stephen Hemminger wrote:
> On Mon, 9 Mar 2020 13:38:53 +0000
> "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:
>
>> Hi Andrze,
>>
>> Adding const qualifier for bulk lookup leads to compilation problems
>> (see http://c-faq.com/ansi/constmismatch.html)
>> Also I don't think it would be good for usability to make users
>> explicitly cast to (const uint8_t **) when passing 'ips' argument. I'd
>> suggest leaving lookup_bulk as is.
>
> Please give a more concrete example. There is no need for explicit cast
> in current C.

Hi Stephen,

In theory, i agree - all modern versions of GCC don't give warnings for 
this code. The problem is, we don't only support modern versions of GCC. 
For a "more concrete example", see the following error in gcc-4.8 on 
CentOS 7:

http://mails.dpdk.org/archives/test-report/2020-March/119455.html

I have reproduced this on my non-CentOS machine with gcc4.8, so it 
appears to be gcc4.8 specific rather than CentOS-specific. That said, 
the same email contains a compile check from RHEL7 with the same 
compiler version, and it didn't trigger the warning, and also it seems 
to be that only meson build has triggered the warning (while i have 
reproduced it with make on my machine).

So, i think it is best to leave lookup_bulk as is, and add const 
qualifiers in other places (for const uint8_t *).
  

On Mon, 9 Mar 2020 18:02:21 +0000
"Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:

> On 09/03/2020 15:52, Stephen Hemminger wrote:
> > On Mon, 9 Mar 2020 13:38:53 +0000
> > "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:
> >  
> >> Hi Andrze,
> >>
> >> Adding const qualifier for bulk lookup leads to compilation problems
> >> (see http://c-faq.com/ansi/constmismatch.html)
> >> Also I don't think it would be good for usability to make users
> >> explicitly cast to (const uint8_t **) when passing 'ips' argument. I'd
> >> suggest leaving lookup_bulk as is.  
> >
> > Please give a more concrete example. There is no need for explicit cast
> > in current C.  
> 
> Hi Stephen,
> 
> In theory, i agree - all modern versions of GCC don't give warnings for 
> this code. The problem is, we don't only support modern versions of GCC. 
> For a "more concrete example", see the following error in gcc-4.8 on 
> CentOS 7:
> 
> http://mails.dpdk.org/archives/test-report/2020-March/119455.html
> 
> I have reproduced this on my non-CentOS machine with gcc4.8, so it 
> appears to be gcc4.8 specific rather than CentOS-specific. That said, 
> the same email contains a compile check from RHEL7 with the same 
> compiler version, and it didn't trigger the warning, and also it seems 
> to be that only meson build has triggered the warning (while i have 
> reproduced it with make on my machine).
> 
> So, i think it is best to leave lookup_bulk as is, and add const 
> qualifiers in other places (for const uint8_t *).
> 

Something else is going on. There are lots of places in code where
something like this is done (without warning).

extern int strcmp(const char *, const char *);

int foo(char *arg)
{
	return strcmp(arg, "foo") == 0;
}
  

On Mon, 9 Mar 2020 18:02:21 +0000
"Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:

> On 09/03/2020 15:52, Stephen Hemminger wrote:
> > On Mon, 9 Mar 2020 13:38:53 +0000
> > "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:
> >  
> >> Hi Andrze,
> >>
> >> Adding const qualifier for bulk lookup leads to compilation problems
> >> (see http://c-faq.com/ansi/constmismatch.html)
> >> Also I don't think it would be good for usability to make users
> >> explicitly cast to (const uint8_t **) when passing 'ips' argument. I'd
> >> suggest leaving lookup_bulk as is.  
> >
> > Please give a more concrete example. There is no need for explicit cast
> > in current C.  
> 
> Hi Stephen,
> 
> In theory, i agree - all modern versions of GCC don't give warnings for 
> this code. The problem is, we don't only support modern versions of GCC. 
> For a "more concrete example", see the following error in gcc-4.8 on 
> CentOS 7:
> 
> http://mails.dpdk.org/archives/test-report/2020-March/119455.html
> 
> I have reproduced this on my non-CentOS machine with gcc4.8, so it 
> appears to be gcc4.8 specific rather than CentOS-specific. That said, 
> the same email contains a compile check from RHEL7 with the same 
> compiler version, and it didn't trigger the warning, and also it seems 
> to be that only meson build has triggered the warning (while i have 
> reproduced it with make on my machine).
> 
> So, i think it is best to leave lookup_bulk as is, and add const 
> qualifiers in other places (for const uint8_t *).
> 

Agree, just drop it from the bulk functions.
The array of array semantics is confusing compiler (and users).
  

On 3/9/20 8:13 PM, Stephen Hemminger wrote:
> On Mon, 9 Mar 2020 18:02:21 +0000
> "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:
> 
>> On 09/03/2020 15:52, Stephen Hemminger wrote:
>>> On Mon, 9 Mar 2020 13:38:53 +0000
>>> "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:
>>>  
>>>> Hi Andrze,
>>>>
>>>> Adding const qualifier for bulk lookup leads to compilation problems
[...]
> Agree, just drop it from the bulk functions.
> The array of array semantics is confusing compiler (and users).

Thank you Vladimir and Stephen for the input.  I'll drop the bulks and
will send V2.

With regards
Andrzej