Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <199909161529.KAA06946@mercury.xraylith.wisc.edu>
To: Chris Faylor <cgf AT cygnus DOT com>
cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: (patch) makethread stdcall/cdecl confusion 
In-Reply-To: Your message of "Thu, 16 Sep 1999 12:23:11 EDT."
             <19990916122311 DOT A655 AT cygnus DOT com> 
Date: Thu, 16 Sep 1999 10:29:50 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

Chris Faylor <cgf AT cygnus DOT com> writes:
> I don't understand.  Why not just fix the functions whose addresses are
> being passed to makethread by adding a WINAPI to each of those?  

"Minimal Change" principle. The other has exactly the same end effect. 

> The > makethread function was supposed to be similar to CreateThread 
> so I think it should take the same arguments.

I agree that if makethread is somewhat modeled on CreateThread then your 
solution is definitely the way to go; I however tend of keep winapi 
functions to a bare minimum to avoid the usual conflicts (the compiler
can't catch some of these errors). 

> It's interesting that this problem has been in cygwin for a very long time.
> Prior to my creation of makethread, all of the functions were being passed
> as arguments to CreateThread.

Actually, it doesn't show up because you're not doing much on the stack
in these functions. However, since I happened to spot it ...

Another issue when you're dealing with thread start routines -- it's 
almost always better to malloc the the parameter argument instead of
passing the address of a stack data element. It'll work in the current
usages in winsup, but this usage can lead to very subtle and hard to
track errors. 

> The other question is why didn't the compiler catch this problem?

The C++ front-end has trouble catching these. Try the following:

  #include <windows.h>

  extern int foo (LPTHREAD_START_ROUTINE);
  static DWORD bar (void *) { return 0; }
  static DWORD WINAPI bar2 (void *) { return 0; }

  int
  main ()
  {
    foo (bar);
    foo (bar2);
    return 0;
  }

And you'll see why I resist using anything but the cdecl calling 
convention in my code. The C front-end does do the right thing.

> So, unless I'm missing something, I have added a WINAPI to all of the
> functions which are eventually called by thread_stub, as well as to
> thread_stub itself.

Works just as well.

Regards,
Mumit