Re: wrong assumptions about pthread_t being numeric

[Matt Rice <ratmice at gmail dot com>]

On Fri, Sep 16, 2011 at 6:02 PM, John Spencer
<maillist-gdbpatches@barfooze.de> wrote:
> On 09/17/2011 02:30 AM, Pedro Alves wrote:
>>
>> On Saturday 17 September 2011 00:13:10, John Spencer wrote:
>>>
>>> On 09/17/2011 01:00 AM, Pedro Alves wrote:
>>>>
>>>> These are only built natively on solaris and aix respectively, so
>>>> let's just leave them alone.
>>>>
>>> I expected it to be desirable for a product in industrial use to be
>>> standard-compliant and not invoking undefined behavior.
>>
>> Those files are tied to those platforms' thread_db/libc implementations.
>> There's absolutely no need to handle some other hipotetical libc that
>> defines pthread_t diferently there. ?If it appears, we'll handle it.
>
>> Chances are, some other changes would be necessary to make it really
>> work, not just build.
>>
>
> exactly. for example in musl's case it is wrong to compare the underlying
> type (which is a struct pointer) with 0.

FWIW, hurd used to do something similar (well, in its case 0 was a
valid, pthread_t, the first one in fact),

I believe that enough things broke gthr from gcc, libobjc, possibly
gdb (don't remember it though..) that they eventually changed their
pthread_t even though it was compliant...