Re: [Boost-bugs] [Boost C++ Libraries] #928: VC6: should __fastcall be defined?

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #928: VC6: should __fastcall be defined?
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2007-08-23 08:26:47

#928: VC6: should __fastcall be defined?
----------------------+-----------------------------------------------------
  Reporter:  chuckm   |       Owner:  johnmaddock
      Type:  Bugs     |      Status:  closed     
 Milestone:           |   Component:  regex      
   Version:  None     |    Severity:  Problem    
Resolution:  wontfix  |    Keywords:             
----------------------+-----------------------------------------------------
Changes (by johnmaddock):

  * status:  reopened => closed
  * resolution:  => wontfix
  * severity:  => Problem

Old description:

> {{{
> In regex_config.hpp, we have:
>
>    #ifndef __WIN32__
>       #define BOOST_RE_CALL
>       #define BOOST_RE_CCALL
>    #else
>       #define BOOST_RE_CALL __fastcall
>       #define BOOST_RE_CCALL __stdcall
>    #endif
>
> I see the need for __stdcall begin defined, since
> sometimes you need this for a system call (such as
> starting a thread, if I recall correctly).
>
> But why __fastcall?  When I'm doing a debug build, I
> don't want __fastcall protocol.  I want the slower,
> easier-to-debug protocol.  When I want __fastcall, I
> turn on the /Gr option.
>
> As it stands, I get a compiler warning when I build
> with the /Ge option for run-time stack checking (which
> I always do in development/debug mode).  It's
> complaining that __fastcall doesn't work work nicely
> with /Ge.  So, I'd like to have BOOST_RE_CALL defined
> to be empty during debug builds.
>
> During release builds, BOOST_RE_CLAL can also be
> defined to be empty: I use the /Gr compiler option,
> which makes all functions use __fastcall by default.
>
> In short, I see no reason why anyone would want
> __fastcall to be defined in regex_config.hpp, while
> it's easy (for me) to see why it shouldn't be there.
>
> Suggested fix: remove the BOOST_RE_CALL macro
> altogether.
> }}}

New description:

 {{{
 In regex_config.hpp, we have:

    #ifndef __WIN32__
       #define BOOST_RE_CALL
       #define BOOST_RE_CCALL
    #else
       #define BOOST_RE_CALL __fastcall
       #define BOOST_RE_CCALL __stdcall
    #endif

 I see the need for __stdcall begin defined, since
 sometimes you need this for a system call (such as
 starting a thread, if I recall correctly).

 But why __fastcall?  When I'm doing a debug build, I
 don't want __fastcall protocol.  I want the slower,
 easier-to-debug protocol.  When I want __fastcall, I
 turn on the /Gr option.

 As it stands, I get a compiler warning when I build
 with the /Ge option for run-time stack checking (which
 I always do in development/debug mode).  It's
 complaining that __fastcall doesn't work work nicely
 with /Ge.  So, I'd like to have BOOST_RE_CALL defined
 to be empty during debug builds.

 During release builds, BOOST_RE_CLAL can also be
 defined to be empty: I use the /Gr compiler option,
 which makes all functions use __fastcall by default.

 In short, I see no reason why anyone would want
 __fastcall to be defined in regex_config.hpp, while
 it's easy (for me) to see why it shouldn't be there.

 Suggested fix: remove the BOOST_RE_CALL macro
 altogether.
 }}}

Comment:

 Just to be clear about the current situation:

 The function call types used by the regex lib are designed to always match
 the call types used in the binaries.  Further, you absolutely can not mix
 a release binary in a debug build or vice versa - they use different
 runtime libraries.

 As I said previously, this prevents an awful lot of support calls for me,
 so it's not going to change unless *lots* of people complain, and at
 present I don't see that.

 Regards, John Maddock

 PS, if this gets opened again, please don't do so anonymously, it makes my
 life much harder!

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/928#comment:7>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.