Re: wrong assumptions about pthread_t being numeric

[Kai Tietz <ktietz70 at googlemail dot com>]

2011/9/29 John Spencer <maillist-gdbpatches@barfooze.de>:
> On 09/17/2011 05:43 PM, John Spencer wrote:
>>
>> On 09/17/2011 04:28 AM, Joel Brobecker wrote:
>>>>
>>>> i disagree. adding a proper solution once is superior to creating
>>>> dozens of special case hacks. ?also it saves a lot of time in the long
>>>> term.
>>>
>>> Based on my experience so far, I have to agree with Pedro.
>>> But if you do have a superior solution, we'll take a look.
>>> I still have to tell you that I won't like it if your solution
>>> makes the code harder to read. Sometimes, that's OK because it
>>> helps achieving portability. ?But when there is no such need for
>>> portability, it just gets in the way. Let's also be pragmatic,
>>> here and fix the problems that we know we have.
>>>
>> it would be nice to have an approach which would just work anywhere and
>> respect the spec,
>> however i currently have not the resources to implement it.
>>
>> thus, as you suggested, i came up with a small patch fixing the issue at
>> hand. the solution should work on any sys/libc combination where
>> sizeof(long) == sizeof(void*) and pthread_t is either a pointer or an int
>> with sizeof equal or less than sizeof long.
>> this should cover all currently existing combinations.
>>
>> i may find more spots in the future which need the application of the
>> macro, and will eventually be sending more patches applying the conversion
>> macro to it.
>>
>> -- JS
>>
>>
>
> knock, knock. anybody here ?
> please tell me wether you accept my patch or not.
>
> -- JS

Well, I can't approve this and I won't.  But I would like to give me 5
cents for this approach.  This approach seems to me bogus, as you are
dependent to sizeof (long) == sizeof (void *), which is a broken
attempt.  It might be a way to use here instead intptr_t instead of
long type.  Nevertheless I admit that the pthread standard doesn't
disallow structure-typed pthread_t, so it might be still worth to
support this for gthread posix.

For windows there is a pthread implementation "winpthread" - hosted by
mingw-w64 project in experimental tree but it will be soon put into
active trunk. This one uses here for pthread_t an integer-scalar
handle instead of a structure, so issues about current implementation
in gthread are working fine.

Regards,
Kai