This is the mail archive of the
mailing list for the GDB project.
Re: wrong assumptions about pthread_t being numeric
- From: John Spencer <maillist-gdbpatches at barfooze dot de>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 01 Oct 2011 03:05:46 +0200
- Subject: Re: wrong assumptions about pthread_t being numeric
- References: <4E73D06F.email@example.com> <firstname.lastname@example.org> <4E73D806.email@example.com> <firstname.lastname@example.org> <4E73F1A4.email@example.com> <20110917022840.GD17681@adacore.com> <4E74C031.firstname.lastname@example.org> <4E83D50B.email@example.com> <CAEwic4YUN78ATPxSz8tC1_xq4aeV-XbQ_ufGGW9GEWn4k3cTzw@mail.gmail.com>
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
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.