On Thursday 10 June 2004 17:12, Ian Zagorskih wrote:

> Some old and very resepected and well-known Real-Time Operating System (ended 
> with X) which is willing to be "the-most-posix-compatible-rtos" defines 
> pthread_t as an integer type. Long, short or just int i don't know. So in 
> their own code and examples they freely use constructions like:
> 
> pthread_t id;
> printf("thread id %d\n", id);
> 
> ...and of course it works just fine. Technically, until code works inside 
> their environment this is correct course threads sub-system is completely 
> implemented inside kernel and userland apps operate only by thread indexes.
> 
> Problems started when i had to port code written with this OS in mind to some 
> other platform, for example NetBSD. Which also follows POSIX way and defined 
> pthread_t but does it in a different maner so here pthread_t is a pointer on 
> some internal data structure. As a result, code which assumes that pthread_t 
> is an integer becomes completely broken. And according to POSIX NetBSD is 
> correct course POSIX dosn't specify *how* exactly pthread_t must be 
> implemented and even states that it may be a pointer (see not so long ago 
> corrections to). Folks from development team were quite confused when we got 
> conversation about this little problem..

I think I can shed a little more light on the origin of that problem.
:-) Until 1003.1-2001 TC2 (read: very recently) pthread_t was specified
to be an arithmetic type.

(However, it needs to be mentioned that treating it as an int, as in
the printf example, would be a no-go for an application; under the
old specification there's nothing wrong with storing a pointer to the
TCB in an appropriately sized arithmetic type, which an int isn't on
several NetBSD platforms.)


But to conclude the issue, if you come across a conflict with the
standard, please file a PR so that the issue can't possibly fall
through the cracks.


Thanks,
- Klaus