Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <3BF384BA.B2DD3ECB@cern.ch>
Date: Thu, 15 Nov 2001 10:02:50 +0100
From: "Lassi A. Tuura" <lassi.tuura@cern.ch>
Organization: Northeastern University, Boston, USA
MIME-Version: 1.0
To: Evan Pollan <evan_pollan@yahoo.com>
CC: Robert Collins <robert.collins@itdomain.com.au>, cygwin@cygwin.com
Subject: Re: pthread_create -- no callback?
References: <20011114212317.56701.qmail@web21002.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> That's all I needed.  My experience is very stale w/ C & C++, but why didn't I
> get at least a compilation warning when I passed the reference to the thread,
> rather than its value?

Because pthread_t == void *.  I am sure cygwin team would accept
a patch that consistently uses for example an opaque type[*].  I
suppose it might be a lot of simple-minded editing, but it would
help catch a lot of trivial errors.

But also make it a habit to check all those return values.  That
too will catch many trivial errors.

[*] Like this: `struct __pthread; typedef __pthread *pthread_t;'.
This is all the client side knows about `__pthread', hence it is
opaque.  The struct is defined in the implementation only.  Works
of course only if the implementation really uses structs.  From a
superficial inspection there's a 'pthread' class on cygwin side so
it would work, but I couldn't quite figure out where the code made
the transition from pthread_t == void * to pthread_t == pthread *.

Cheers,
//lat
-- 
Any coward can fight a battle when he's sure of winning; but
give me the man, who has pluck to fight when he's sure of
losing.  That's my way, sir; and there are many victories
worse than a defeat.  --George Eliot

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/