Jonathan Wakely <jwakely....@gmail.com> writes:
>>> I didn't like that feature of the patch much either, but the signature
>>> of the mutex_init function is specified in gthr.h:
>>>
>>> __GTHREAD_MUTEX_INIT_FUNCTION
>>> some systems can't initialize a mutex without a
>>> function call. On such systems, define this to a
>>> function which looks like this:
>>> void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *)
>>>
>>> The recursive one says it should have the same signature, and I (maybe
>>
>> I don't see this, neither in gthr.h nor in gthr-posix.h.
>
> lines 54-62 in http://gcc.gnu.org/viewcvs/trunk/libgcc/gthr.h?view=markup
I think that's overinterpreting the comment.
__gthread_recursive_mutex_init_function happily returns errors with no
indication it should be otherwise.
>>> wrongly) assumed the cond_init one should too.
>>
>> I don't think this is cast in stone: the gthr*.h headers aren't
>> installed in a public place and aren't considered an external interface
>> to the best of my knowledge, so it should be possible to change.
>>
>> Currently, __GTHREAD_MUTEX_INIT_FUNCTION is only used in libgcc,
>> libgfortran, and libstdc++ (and __GTHREAD_COND_INIT_FUNCTION only in
>> libstdc++), so changing the 13 calls is doable.
>
> Private ports which provide their own gthr header (I think they're
> rare, but do exist) would need to modify their functions to return an
> integer - but at least it would be a compile-time failure so they'd
> know to change it.
Right, and that's the cost of keeping a port out of the FSF tree.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
