> msvcr80.dll!__crt_debugger_hook(int _Reserved=) Line 65 C > msvcr80.dll!_invalid_parameter(const wchar_t * > pszExpression=0x00000000aff9055c, const wchar_t * > pszFunction=0x0000000000000000, const wchar_t * pszFile=0x0000000000000000, > unsigned int nLine=6, unsigned __int64 pReserved=0) Line 212 C++ > msvcr80.dll!signal(int signum=1245184, void (int)* > sigact=0x0000000000130000) Line 419 + 0x23 bytes C > libeay32.dll!pushsig() Line 606 + 0x11 bytes C
> Theoretically, it could be problem with VC8 compilers on Windows-64A, > although not very likely. Depends on defintion of "problem." When Microsoft decides to throw an fatal exception as above on unimplemented signal number passed to signal function, instead of just returning an error code like they and the rest of the world used to for many years. Is it a problem? Because that's what happens. But unlike notorious str* thing, when it's possible to regain compatibility by defining _CRT_SECURE_NO_DEPRECATE, it doesn't seem to be possible to revert to original signal behavious, as exception is hard-coded into msvcr80.dll. They say one can install _set_invalid_parameter_handler, but it's hardly good style for library to steal handlers application might have set and it's not clear how to detect presense of new run-time [compiler version alone is not sufficient, as for example Platform SDK comes with new compiler and elder MSVCRT]. http://cvs.openssl.org/chngview?cn=14451 and case is being dismissed. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
