threads / discuss / 20619

quick question about __stdcall at run-command.c mingw.c

Subject: quick question about __stdcall at run-command.c mingw.c

## tl;dr

6 messages between Aug 16, 2009 and Aug 17, 2009.

replies: 5people: 4as markdown or json

Frank Li· Aug 16, 2009, 23:19 UTC · lore
I am tring to clear VC build patch.
I found __stdcall position break MSVC build.
static __stdcall unsigned run_thread(void *data)

MSVC require __stdcall should be between return type and function name. like static unsigned __stdcall run_thread(void *data)

I think msys gcc should support MSVC format.
Should I directly change to MSVC format or add _MSC_VER marcro like

#if defined(__MINGW32__) static __stdcall unsigned run_thread(void *data) #elif defined(_MSC_VER) /*MSVC must put __stdcall between return value and function*/ static unsigned __stdcall run_thread(void *data) #endif

Pat Thoyts· Aug 17, 2009, 00:03 UTC · re: Frank Li · lore

Re: [msysGit] quick question about __stdcall at run-command.c mingw.c

2009/8/17 Frank Li <lznuaa@gmail.com>:
Show 21 quoted lines
>
> I am tring to clear VC build patch.
>
> I found __stdcall position break MSVC build.
>
> static __stdcall unsigned run_thread(void *data)
>
> MSVC require __stdcall should be between return type and function name.
> like
> static unsigned __stdcall run_thread(void *data)
>
> I think msys gcc should support MSVC format.
>
> Should I directly change to MSVC format or add _MSC_VER marcro like
>
> #if defined(__MINGW32__)
> static __stdcall unsigned run_thread(void *data)
> #elif defined(_MSC_VER) /*MSVC must put __stdcall between return value
> and function*/
> static unsigned __stdcall run_thread(void *data)
> #endif

The win32 api prototype used for thread entry functions is declared as a DWORD (WINAPI *LPTHREAD_START_ROUTINE)(LPVOID) type in the mingw headers and WINAPI as #define WINAPI __stdcall. This is true for the MSVC headers as well. So gcc and msvc are happy using the same definition for such a function and just "static unsigned long WINAPI run_thread(void *)" might well be sensible.

Johannes Sixt· Aug 17, 2009, 07:52 UTC · re: Pat Thoyts · lore

Re: [msysGit] quick question about __stdcall at run-command.c mingw.c

Pat Thoyts schrieb:
Show 28 quoted lines
> 2009/8/17 Frank Li <lznuaa@gmail.com>:
>> I am tring to clear VC build patch.
>>
>> I found __stdcall position break MSVC build.
>>
>> static __stdcall unsigned run_thread(void *data)
>>
>> MSVC require __stdcall should be between return type and function name.
>> like
>> static unsigned __stdcall run_thread(void *data)
>>
>> I think msys gcc should support MSVC format.
>>
>> Should I directly change to MSVC format or add _MSC_VER marcro like
>>
>> #if defined(__MINGW32__)
>> static __stdcall unsigned run_thread(void *data)
>> #elif defined(_MSC_VER) /*MSVC must put __stdcall between return value
>> and function*/
>> static unsigned __stdcall run_thread(void *data)
>> #endif
> 
> The win32 api prototype used for thread entry functions is declared as
> a DWORD (WINAPI *LPTHREAD_START_ROUTINE)(LPVOID) type in the mingw
> headers and WINAPI as #define WINAPI __stdcall. This is true for the
> MSVC headers as well. So gcc and msvc are happy using the same
> definition for such a function and just "static unsigned long WINAPI
> run_thread(void *)" might well be sensible.
Change the code to
	static unsigned __stdcall run_thread(void *data)

The documentation explictly says: "The routine at start_address passed to _beginthreadex must use the __stdcall calling convention...". So __stdcall it is.

-- Hannes
Johannes Schindelin· Aug 17, 2009, 08:21 UTC · re: Johannes Sixt · lore

Re: [msysGit] quick question about __stdcall at run-command.c mingw.c

Hi,
On Mon, 17 Aug 2009, Johannes Sixt wrote:
Show 12 quoted lines
> Pat Thoyts schrieb:
> > 2009/8/17 Frank Li <lznuaa@gmail.com>:
> >> I am tring to clear VC build patch.
> >>
> >> I found __stdcall position break MSVC build.
> >>
> >> static __stdcall unsigned run_thread(void *data)
> >>
> >> MSVC require __stdcall should be between return type and function 
> >> name. like static unsigned __stdcall run_thread(void *data)
> >>
> >> I think msys gcc should support MSVC format.
I think that it does.
But it is _your_ duty to check.
Show 8 quoted lines
> >> Should I directly change to MSVC format or add _MSC_VER marcro like
> >>
> >> #if defined(__MINGW32__)
> >> static __stdcall unsigned run_thread(void *data)
> >> #elif defined(_MSC_VER) /*MSVC must put __stdcall between return value
> >> and function*/
> >> static unsigned __stdcall run_thread(void *data)
> >> #endif

Noooo! NO _MSC_VER crap in mingw.c. Really. I am able to repeat that as often as you want me, but I'd prefer not to.

Show 14 quoted lines
> > The win32 api prototype used for thread entry functions is declared as
> > a DWORD (WINAPI *LPTHREAD_START_ROUTINE)(LPVOID) type in the mingw
> > headers and WINAPI as #define WINAPI __stdcall. This is true for the
> > MSVC headers as well. So gcc and msvc are happy using the same
> > definition for such a function and just "static unsigned long WINAPI
> > run_thread(void *)" might well be sensible.
> 
> Change the code to
> 
> 	static unsigned __stdcall run_thread(void *data)
> 
> The documentation explictly says: "The routine at start_address passed to
> _beginthreadex must use the __stdcall calling convention...". So __stdcall
> it is.
I could not agree more.

Ciao, Dscho

Johannes Sixt· Aug 17, 2009, 08:43 UTC · re: Johannes Schindelin · lore

Re: [msysGit] quick question about __stdcall at run-command.c mingw.c

Johannes Schindelin schrieb:
Show 17 quoted lines
> On Mon, 17 Aug 2009, Johannes Sixt wrote:
>> Pat Thoyts schrieb:
>>> 2009/8/17 Frank Li <lznuaa@gmail.com>:
>>>> I am tring to clear VC build patch.
>>>>
>>>> I found __stdcall position break MSVC build.
>>>>
>>>> static __stdcall unsigned run_thread(void *data)
>>>>
>>>> MSVC require __stdcall should be between return type and function 
>>>> name. like static unsigned __stdcall run_thread(void *data)
>>>>
>>>> I think msys gcc should support MSVC format.
> 
> I think that it does.
> 
> But it is _your_ duty to check.

Cool down. Asking for "please could you check whether this works" *if* you don't have the infrastructure to test it yourself is certainly dutyful enough.

Do you have an Irix, Solaris, HP box on your desk next to your Linux, so that you don't have to ask others to test your patches?

-- Hannes
Johannes Schindelin· Aug 17, 2009, 09:12 UTC · re: Johannes Sixt · lore

Re: [msysGit] quick question about __stdcall at run-command.c mingw.c

Hi,
On Mon, 17 Aug 2009, Johannes Sixt wrote:
Show 25 quoted lines
> Johannes Schindelin schrieb:
> > On Mon, 17 Aug 2009, Johannes Sixt wrote:
> >> Pat Thoyts schrieb:
> >>> 2009/8/17 Frank Li <lznuaa@gmail.com>:
> >>>> I am tring to clear VC build patch.
> >>>>
> >>>> I found __stdcall position break MSVC build.
> >>>>
> >>>> static __stdcall unsigned run_thread(void *data)
> >>>>
> >>>> MSVC require __stdcall should be between return type and function 
> >>>> name. like static unsigned __stdcall run_thread(void *data)
> >>>>
> >>>> I think msys gcc should support MSVC format.
> > 
> > I think that it does.
> > 
> > But it is _your_ duty to check.
> 
> Cool down. Asking for "please could you check whether this works" *if* 
> you don't have the infrastructure to test it yourself is certainly 
> dutyful enough.
> 
> Do you have an Irix, Solaris, HP box on your desk next to your Linux, so 
> that you don't have to ask others to test your patches?
This is Windows.  Frank has Windows.

Downloading msysGit does not incur any cost. Actually running the whole thing from the net installer just takes a little time and a two-digit megabyte download.

I put a lot of work into making this procedure as painless to use (for other people, it caused me a lot of pain). So Frank might just as well not let my effort go to hell.

Of course, Frank could ask one of the few msysGit contributors to try to compile something he prepared, wait for the results and possibly fix things for another round. This appears as a rather poor use of everybody's time, methinks.

Ciao, Dscho

← back to recent threads