On 17 Oct 2025, at 19:11, Ilya Maximets wrote:
> '-Wuninitialized-const-pointer' complains about passing uninitialized
> data into a function via a const pointer. That's a valid concern,
> since normally the function accepting a const argument wouldn't write
> to it, but will likely use the data.
>
> However, we do have some cases of such a coding pattern in OVS today
> and they generate a ton of warnings with clang 21.
>
> The main offenders of this are all the types of locks in OVS: mutex,
> rwlock, spinlock. All the locking functions accept const pointers
> and then do a CONST_CAST inside. This is useful for the cases where
> we have a lock protecting a structure and want to have some read-only
> function that accepts this structure, e.g.:
>
> struct my_type {
> struct ovs_mutex mutex;
> int value;
> };
>
> int get_value(const struct my_type *p)
> {
> int res;
>
> ovs_mutex_lock(&p->mutex);
> res = p->value;
> ovs_mutex_unlock(&p->mutex);
>
> return res;
> }
>
> If the ovs_mutex_lock() required non-const argument, then we'd have
> to use CONST_CAST for every lock/unlock, or we would have to make the
> original pointer 'p' non-const, cascading the change through all the
> callers of this "read-only" functions.
>
> However, it's totally reasonable for the mutex init and destroy to
> not have a constant argument, since we're explicitly trying to change
> it and the initialization and destruction likely not happening for
> the constant parent structure.
>
> Let's convert both init and destroy API for all the locks to accept
> non-const arguments. This makes clang happy as we're no longer
> passing in the uninitialized locks as const.
>
> This technically changes the API, but we're relaxing the restriction,
> so it shouldn't be a concern. All the code that used these functions
> before should still work fine.
>
> Signed-off-by: Ilya Maximets <[email protected]>
Thanks for the change Ilya, it makes sense to me.
Acked-by: Eelco Chaudron <[email protected]>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
