This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Replace MUTEX_INITIALIZER with _LIBC_LOCK_INITIALIZER in generic code
- From: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 23 Aug 2016 21:27:02 +0200
- Subject: Re: Replace MUTEX_INITIALIZER with _LIBC_LOCK_INITIALIZER in generic code
- Authentication-results: sourceware.org; auth=none
- References: <20160820143610.GA14327@var> <86732dd1-9c82-0d07-a45d-3b94fd4e2ad6@redhat.com> <20160820173816.GH28098@var> <64f4c6a1-6e9b-8056-04b4-1c626e224cf5@redhat.com>
Florian Weimer, on Mon 22 Aug 2016 14:45:14 +0200, wrote:
> On 08/20/2016 07:38 PM, Samuel Thibault wrote:
>
> >>Because it was a special case for malloc and appears to be a Mach
> >>identifier, not a glibc identifier.
> >
> >Then let's call it another way. But seeing this kind of code:
> >
> >static mutex_t list_lock = _LIBC_LOCK_INITIALIZER;
> >
> >looks really odd to the reader: why would I be using
> >_LIBC_LOCK_INITIALIZER to initialize a mutex_t? I shouldn't have to
> >have a look at the mutex_t definition to know why it happens to be
> >right.
>
> I have just posted the remaining two conversion patches, split into an
> automated and a manual part.
Ah, ok, thanks :)
Samuel