Re[2]: [lmi] dealing with standard C functions implemented as macros

[Vadim Zeitlin]

On Mon, 24 Mar 2008 16:24:58 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2008-03-23 20:45Z, Vadim Zeitlin wrote:
GC> > 
GC> >  I'd like to know if there is an official policy for using standard
GC> > functions which can be implemented as macros.
GC> 
GC> C++1998, 17.4.1.2/6 says:
GC> 
GC> "Names that are defined as functions in C shall be defined as
GC> functions in the C++ Standard Library."
GC> 
GC> and its footnote 159 says:
GC> 
GC> "This disallows the practice, allowed in C, of providing a
GC> 'masking macro' in addition to the function prototype."

 Thanks, I've completely missed this!

GC> AFAICT, msvc is wrong in this case.

 Yes, definitely. And looking at VC9 headers they have even corrected this
in the later versions so the workaround is only needed for VC7 and VC8.

GC> >  I see 2 possible solutions:
GC> > 
GC> > 1. Do an "#undef ferror" to force the use of a function version. I'm not
GC> >    100% sure if an implementation is allowed to define ferror() solely as
GC> >    a macro but I don't think, even though I can't find the exact reference
GC> >    right now I believe that the function version must be always provided.
GC> >    But if there is any uncertainty about this we could, of course, use 
this
GC> >    #undef for MSVC only which is known to provide both macro and function
GC> >    versions of ferror().
GC> 
GC> Sounds like a good approach to me. I'd prefer something like:
GC> 
GC> 'config_msvc.hpp' [a new file, like 'config_bc551.hpp']

 Yes, I've already created such file and will add this workaround there.

 Thanks,
VZ