Re: [Quickfix-developers] Confused by possible bug in Utility.cpp / thread_spawn

[Djalma R. d. S. F. <drs...@gm...>]

Hi Frank,

Is the name of the function the function pointer itself?
IMHO, this is just a matter of syntax and compiler implementation detail.
You might want to check the C99 spec and the compiler documentation.

Djalma


On Tue, Jan 15, 2013 at 8:05 PM, K. Frank <kfr...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Mike!
>
> On Tue, Jan 15, 2013 at 1:10 PM, Mike Gatny <mg...@co...> wrote:
> > It works with the VS compiler (32-bit, anyway).  Can you post the actual
> > error message that mingw-w64 is giving you?
>
> Yes, I'd be happy to post the mingw-w64 error message.
>
> But before I do, I would like to check whether the code looks to you
> like it has an error, or whether I'm missing something simple about
> relatively basic c++.  (Again the issue is that I see a
> pointer-to-pointer-to-function (double pointer) being passed, while a
> pointer-to-function (single pointer) is expected.)  Does this look
> like an error to you?
>
> Anyway, here's the mingw-w64 error message:
>
>    Utility.cpp: In function 'bool FIX::thread_spawn(unsigned int
> (*)(void*), void*, FIX::thread_id&)':
>    Utility.cpp:510:56: error: cannot convert 'unsigned int
> (**)(void*)' to 'unsigned int (*)(void*)' for argument '3' to
> 'uintptr_t _beginthreadex(void*, unsigned int, unsigned int
> (*)(void*), void*, unsigned int, unsigned int*)'
>
> In a way, I'm not surprised that you don't see the issue with visual
> studio, because if you did, you would have changed the code.  So
> I wonder whether visual studio might be doing something wrong or
> non-standard here.  (I'm not aware of anything, but I'm not that
> expert with visual studio.)  Or maybe g++ / mingw-w64 is doing
> something non-standard.  But again, when I parse the code by
> eye, I come up with a type mismatch.
>
> (Just to note, the linux builds with g++ wouldn't have caught this
> because this is in the windows-specific part of the threading code.
> I verified -- at least to my eye -- that the analogous posix-threading
> part of the code doesn't have this issue.)
>
> By the way, if I "fix" the code by changing
>
>    result = _beginthreadex( NULL, 0, &func, var, 0, &id );
>
> to
>
>    result = _beginthreadex( NULL, 0, func, var, 0, &id );
>
> (that is, removing what appears to be the extra '&' from "&func")
> the code compiles under mingw-w64.  I don't know whether the
> code runs correctly because I haven't been able to compile all
> of the rest of the code.  But I would be worried about just making
> this change blindly because there is something going on that I
> don't understand.
>
>
> Thanks for helping me sort this out.
>
>
> K. Frank
>
>
> ------------------------------------------------------------------------------
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>