Re: [PATCH v3] locking/local_lock: s/l/__l/ and s/tl/__tl/ to reduce risk of shadowing

[Vincent Mailhol <mailhol@kernel.org>]

On 09/10/2025 at 21:43, Sebastian Andrzej Siewior wrote:
> On 2025-10-09 21:39:07 [+0900], Vincent Mailhol wrote:
>> Hi Sebastian,
> Hi Vincent,
> 
>> On 09/10/2025 at 19:39, Sebastian Andrzej Siewior wrote:
>>
>> (...)
>>
>>> @@ -223,12 +223,12 @@ typedef spinlock_t local_trylock_t;
>>>  #define INIT_LOCAL_LOCK(lockname) __LOCAL_SPIN_LOCK_UNLOCKED((lockname))
>>>  #define INIT_LOCAL_TRYLOCK(lockname) __LOCAL_SPIN_LOCK_UNLOCKED((lockname))
>>>  
>>> -#define __local_lock_init(l)					\
>>> +#define __local_lock_init(__l)					\
>>>  	do {							\
>>> -		local_spin_lock_init((l));			\
>>> +		local_spin_lock_init((__l));			\
>>>  	} while (0)
>>>  
>>> -#define __local_trylock_init(l)			__local_lock_init(l)
>>> +#define __local_trylock_init(__l)			__local_lock_init(__l)
>>>  
>>>  #define __local_lock(__lock)					\
>>>  	do {							\
>>
>> The parameters of a function like macro can not shadow existing
>> symbols because, when invoked, these parameters would be substituted
>> during the macro expansion by the actual arguments. Only the local
>> variables declared in the macro would survive after the preprocessor
>> and thus only those may cause shadowing.
>>
>> So this last part of the patch is not needed.
> 
> Right, but then we have the same __l variable in the whole file. Isn't
> this worth something?

What I really wanted to point out is that this is not needed in
regards to the shadowing problem. So this part feels a bit out of
scope of what the patch is trying to achieve.

That said, if you as a maintainer think that it is better to add this
for the global harmony of the file, then I am OK. I wouldn't do that
in a file which I maintain, but the maintainer here is you, not me. It
make sense that you do it your preferred way.

In other words, if you like it this way, keep the patch as is :)


Yours sincerely,
Vincent Mailhol