[patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

[Jonathan Wakely]

On 26/09/15 22:49 +0200, Florian Weimer wrote:
>On 09/26/2015 09:52 PM, Jonathan Wakely wrote:
>
>> Would changes like this be suitable for _FORTIFY_SOURCE?
>
>> diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
>> index 5e5ced1..074bf26 100644
>> --- a/libstdc++-v3/include/std/mutex
>> +++ b/libstdc++-v3/include/std/mutex
>> @@ -70,7 +70,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>      __recursive_mutex_base& operator=(const __recursive_mutex_base&) = delete;
>>
>>  #ifdef __GTHREAD_RECURSIVE_MUTEX_INIT
>> +# if _GLIBCXX_ASSERTIONS && defined(PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP)
>> +    // Use an error-checking mutex type when assertions are enabled.
>> +    __native_type  _M_mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
>> +# else
>>      __native_type  _M_mutex = __GTHREAD_RECURSIVE_MUTEX_INIT;
>> +# endif
>
>I think this is incorrect.
>
>If you try to lock an error-checking mutex recursively, the operation
>fails, and it does *not* increment the internal lock counter (the mutex
>may not even have one).  This means a subsequent unlock operation will
>release the mutex too early.
>
>The trylock will be have differently, too.
>
>POSIX recursive mutexes are already error-checking in that sense
>(self-deadlock cannot happen, and an unlock when not lock is defined to
>return an error), so I don't think anything like that is even needed.

Doh, sorry, I meant this instead i.e. the non-recursive mutex.

(I forgot that I'd moved the non-recursive std::mutex definition to a
new file, and just edited the first thing I saw in include/std/mutex!)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 673 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150927/94b499ce/attachment.bin>