This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wrong assumptions about pthread_t being numeric

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]