[cfe-dev] [PATCH] Make libcxx compile on x86_64 Linux w/ g++ 4.4.3

[Howard Hinnant]

On Jun 2, 2010, at 1:25 PM, Sebastian Redl wrote:

> Howard Hinnant wrote:
>> Thanks Matt.  What is pthread_t on your system?  And are you sure that assigning NULL to it is putting it into a state that means "not a thread"?
>> 
> glibc defines pthread_t as unsigned long. Assigning NULL to it is
> definitely not a good idea; at the very least, GCC ought to generate
> warnings about the misuse of NULL. (And so would Clang.)

Agreed.  I've changed to '0', but haven't checked it in yet.

> I've looked at the Single Unix Specification, and I don't think
> pthread_t is supposed to even have a "not a thread" value.

You are correct.

> So you can
> either go the separate bool way for glibc systems, or look at the glibc
> code to find a valid sentinel and pray they don't change anything.

If the separate bool is needed for glibc, I'd prefer it go under an #ifdef.  I don't want to sacrifice performance for portability.

> For what it's worth, current glibc stores a pointer in pthread_t too, so
> 0 can probably be used as a sentinel for now.

Good.  The posix community is aware (I think) that a sentinel value is desired.  It comes in very handy when a function needs to detect if this thread was the last one to execute it (like a recursive mutex).

> That said, be aware that
> it unconditionally dereferences that pointer, so if you accidentally
> pass it to a pthread_* function, you'll get a segmentation fault, not an
> error.

This is allowed behavior for pthread_join and pthread_detach (according to the posix spec).  Though I would think it higher quality to return EINVAL.

Thanks Sebastian.

-Howard