stdlib: resolve a double lock init issue after fork [BZ #32994]

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 16/06/25 15:44, Florian Weimer wrote:
>> * Adhemerval Zanella Netto:
>> 
>>> On 16/06/25 15:20, Florian Weimer wrote:
>>>> * Davide Cavalca:
>>>>
>>>>> +  memcpy (&lock, &reset_lock, sizeof(lock));
>>>>
>>>> May I change this line to
>>>>
>>>> +  memcpy (&lock, &reset_lock, sizeof (lock));
>>>>
>>>> (one more space)?  Then I think it's ready to go in.
>>>
>>> Should we change __libc_rwlock_init and other init wrappers instead?
>>>
>>> Because we will hit this very issue if/when we start to use any other
>>> lock other than the internal-only ones on some code that might require
>>> reseting after fork.
>> 
>> Hmm, I had not considered that.  It would mask any bug that valgrind
>> would otherwise detect, so I'm not sure if it's the right approach.
>
> These macros are only internally and we can then assure there are
> semantically equivalent to external ones.  I think adding these
> memcpy workarounds on every call is not a good approach as well.

If there are multiple calls, we can introduce a helper function.  Doing
this at the __libc_rwlock_init level would lose this kind of misuse
detection for internal locks.  In general, we want these diagnostics,
just not immediately after fork.

Thanks,
Florian