Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Mon, 8 May 2000 11:50:52 -0400 To: Cygwin Developers Subject: Re: Reason for cover functions in pthread.cc Message-ID: <20000508115052.K13670@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cgf AT cygnus DOT com, Cygwin Developers References: <000001bfb89f$94694120$6401a8c0 AT jupiter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.12i In-Reply-To: <000001bfb89f$94694120$6401a8c0@jupiter>; from pfisher@plexware.com on Sun, May 07, 2000 at 10:43:31PM -0500 On Sun, May 07, 2000 at 10:43:31PM -0500, Paul K. Fisher wrote: >Is there a reason to keep the cover functions in pthread.cc? These simply >call "__" prefixed versions in thread.cc, where the real implementation is >provided. > >For example: >int >pthread_attr_init (pthread_attr_t * attr) >{ > return __pthread_attr_init (attr); >} I don't know of any reason for this practice. It has always mystified me. Do things __pthread_attr_init exist in the spec? If so, the place to handle this is in cygwin.din not in a wrapper function. cgf