Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Uhm, where are they then???? Looking at MSDN it is supposed to be a valid function. Can you find it in any DLL? I find it in Clbr107.dll but that is a WATCOM distribution and could have been put there by something else. Hmm... I wonder if these are static functions within MSVCRT.LIB? It is possible for an import library on win32 to contain the dll import information as well as static functions and data.
On my pc they are exported from msvcp60.dll and msvcp50.dll, following all the mangled C++ symbols.
In my msdn docs, these functions are described in the C++ library section.
Ok. Here's what I've decided. I'll wrap them in cplusplus conditionals. The msvcp60.dll is readily available from the net, most predominately http://www.iol.ie/~locka/mozilla/runtime60.zip, so eliminating them is overkill.
Well, I don't really agree with the __cplusplus wrapper business (they are not C++, regardless of where MS puts them) , but to be consistent, the same should be done for
typedef wchar_t wctrans_t;
wint_t towctrans(wint_t, wctrans_t);
wctrans_t wctrans(const char*);
wctype_t wctype(const char*);
For same reason.
I agree. What about HAVE_MSVCP? Then one could autoconfigurate it.
HAVE_MSVCP is much better.
I reverted the change and added comments that the symbols are resolved via -lmsvcp60. I also gave reference to the fact that msvcp60.dll is easily obtainable from the web.
I decided against HAVE_MSVCP also. It really isn't appropriate to protect these at all.