Daniel wrote:
> Doesn't our LIBSSH2_API already make our external API use the
> correct exposure stuff?
That's a slightly different issue - it's used for symbols exported
publically from the library to be consumed by the caller. It's not the same
as callbacks that are exposed by the caller to be consumed by the library.
I thought I'd mention this out of order because it's the basis of my
understanding and thus the reason for my changes.
> Callbacks? But you declare the callbacks in your code.
Sure, in .NET you declare them as delegate types that are then marshaled
into unmanaged space as function pointers. I know VB6 can generate function
pointers in native code, I can't speak for other languages I haven't used
but I believe M$ defined stdcall for callbacks for exactly this reason -
everyone supports it and there's no interaction problems.
> And isn't the key about how it gets called, not
> about how it is exposed? I mean, a callback doesn't have to
> be exposed at all.
Exactly correct - the callback function pointer is called using the
prototype in the libssh2 library, which is currently cdecl, even if it's
exposed by the caller as stdcall. It's almost certainly not publically
exported, but at the moment of transition between caller and library, the
function pointer is exposed, undecorated.
As a result, both caller and callee have to agree on precisely which
declaration to use or you get stack errors and memory corruption. This is
exactly why after a quick diagnostic to find out why my code was crashing
just after the callback returned I determined that changing the prototype in
libssh2 fixed the problem.
I admit that I didn't investigate whether .NET would be able to expose the
callback using cdecl or not, but I know that other languages cannot, they
only use stdcall.
I found that the macro definitions for callbacks didn't allow decoration,
even if I used LIBSSH2_API instead of WINAPI, hence using typedefs instead
of macros.
> I - and I can only urge everyone else who works on libssh2
> and write patchs for it etc - am working with the latest git version.
I'll download another snapshot to regenerate the patch against but I don't
have capability at this time to continuously pull in new git versions, even
if the project I'm working on is internal - at some point I have to complete
it!
> I'm interested, but not for 1.2. I'm feeling far too lonely
> on the committing front to take on any new work before I can
> ship the next release.
No worries, just thankful for all your work, and apologies if all I'm doing
is making life harder.
Regards,
-- Mark Smith _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2009-07-15