Alexander,
>
> I am not _absolutely_ sure if the usage of extern "C" will solve your
> problem, but I think you should at least try if you don't want to use
> the STL or roguewave or similar instead.
Actualy one of the first things I tried was extern "C", it did not help.
Thinking back I still do not think it should help.
extern "C" is a lingage specification, it is very importing to add it in
a C++ DLLs especially if those DLLs are going to be explicitly
loaded and the addresses of the export functions should be gained
by calling GetProcAddress( "functions name" ). Without extern C,
the name of the function will be changed ( _ will be prepennd and
@+stock information append (depand on the function call
(__stdcall or __cdecl))).
If the DLL is loaded implicitly (using the lib and header file), the
function could be accessed also without extern "C"! (I tested it).
The problem I have is in the implementation macro and not in the
declaration. For example
STACK_OF(type) *sk_##type##_new( int (*cmp)(type **,type **)) \
{ return (STACK_OF(type) *)sk_new(cmp); } \
the argument recieved by sk_##type##_new is an int (*)( type**,
type**)
The functions calls sk_new with the argument cmp ( int (*)( type**,
type**) ) while sk_new expect an int (*)() as an argument, as
declared in stack.h.
Now there are 3 such functions that call such a function and only
those three cause a compiler error. If I cast them:
{ return (STACK_OF(type) *)sk_new((int (*)())cmp); } \
the problem was solved.
Anyway as I mention in the previous mail, I received an answer in
the developer list which indicate that this have bin fixed in the new
snapshot.
Thanks for answer.
Dror
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
