Message-ID: <005901c94d64$d3462df0$4001a8c0@mycomputer>
From: "John Emmas" <johne53@tiscali.co.uk>
To: <cygwin@cygwin.com>
References: <003a01c94d55$62193d70$4001a8c0@mycomputer> <492938E8.30603@sh.cvut.cz>
Subject: Re: pthread_t
Date: Sun, 23 Nov 2008 12:12:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; 	format=flowed; 	charset="Windows-1252"; 	reply-type=original
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

----- Original Message ----- 
From: "Vaclav Haisman"
Sent: 23 November 2008 11:05
Subject: Re: pthread_t
>
> The program is wrong. The pthread_t type is opaque. You should not
> expect anything.
>
> [...]
>
> The only header that you should use to get pthread_t type is pthread.h.
>
Thanks Vaclav, you're absolutely right.  On further investigation, this
turned out to be due to the fact that the program is expecting 'pthread_t'
and 'pthread_key_t' to be equivalent.  When they were both unsigned long,
the compiler would perform a cast automatically.  However, when they're
both pointers to struct, the compiler (understandably) complains.  In this
case I should be able to get around the problem by casting, unless you
can think of a better solution?

John

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/