Re: wrong assumptions about pthread_t being numeric

[John Spencer <maillist-gdbpatches@barfooze.de>]

On 09/29/2011 10:26 AM, Kai Tietz wrote:
>
> 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.

gdb assumes that the type of thread_t is a long. that is the bogus part.
my macro just explicitly casts it to long. on archictectures where 
sizeof(void*) != sizeof(long) it would possible truncate or zeropad the 
value, but still return a (hopefully unique) number.
if it isnt guaranteed to return a unique number on this not-yet-existing 
platform, there had to be some ifdef'd code for that.
for libc's that use a struct type for pthread_t, there needs to be a 
specific workarounds, as others already pointed out.

> 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
>