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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

In the last couple of years, Microsoft has made a huge effort to be
compliant with the C/C++ standard.
Perhaps, the problem relies in the fact that you are using MinGW which has
been forced to conform to C89.

http://www.mingw.org/wiki/C99

If so, you are right, an #ifdef for mingw would fix it.

But, why don't you try Visual Studio Express for free?

On Thu, Jan 17, 2013 at 11:16 AM, K. Frank <kfr...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello Djalma!
>
> Thanks for taking a look at this.
>
> On Thu, Jan 17, 2013 at 7:17 AM, Djalma Rosa dos Santos Filho
> <drs...@gm...> wrote:
> >
> > Hi Frank,
> >
> > Is the name of the function the function pointer itself?
>
> As I understand c++ (and c), yes.  When you use the name of a
> it "decays" into a function pointer (in the same way that the name
> of an array decays into a pointer to the first element of the array).
>
> > IMHO, this is just a matter of syntax and compiler implementation detail.
> > You might want to check the C99 spec and the compiler documentation.
>
> It is syntax, but I think it's standardized, and therefore it shouldn't
> be a compiler-specific detail.
>
> Also, the unix branch for the code (line 488 of Utility.cpp):
>
>    if( pthread_create( &result, 0, func, var ) != 0 ) return false;
>
> does not have the '&' on "func" and compiles fine.  Note, that "func"
> is not the name of a function, but rather a formal argument to the
> thread_spawn function (line 479):
>
>    bool thread_spawn( THREAD_START_ROUTINE func, void* var, thread_id&
> thread )
>
> (If I parse the typedef of THREAD_START_ROUTINE correctly,
> THREAD_START_ROUTINE is indeed a pointer to a function in
> both the windows and unix branches of the code.)
>
> So the unix branch looks right -- func is a function pointer, and
> there is no '&' to take the pointer to the pointer.
>
> But the windows branch (line 484):
>
>     result = _beginthreadex( NULL, 0, &func, var, 0, &id );
>
> has the '&' so "&func" is a pointer to func (the address of wherever
> func is stored on the stack when thread_spawn is called), and
> func is a pointer to a function, so "&func" is, as I read t, a
> pointer-to-pointer-to-function.
>
> What I don't understand, following up on Mike's comment, is
> why this would compile with visual studio.  (I don't have visual
> studio to test.)  To me it looks like a straightforward c++ issue.
> Either visual studio is doing something non-standard (wrong),
> of I've missed a different typedef hidden somewhere in an
> #ifdef somewhere in the windows branch of the code.  (But, if
> so, it would be a typedef that mingw-w64 isn't picking up on.)
>
> So I think "&func" is an error.  But I am also puzzled, because
> it compiles with visual studio, which doesn't make sense to me.
>
> > Djalma
>
>
> Thanks for your help.
>
>
> K. Frank
>
>
> > On Tue, Jan 15, 2013 at 8:05 PM, K. Frank <kfr...@gm...> wrote:
> >>
> >> 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 Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>