This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: (patch) makethread stdcall/cdecl confusion


Chris Faylor <cgf@cygnus.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]