| delorie.com/archives/browse.cgi | search |
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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |