Hi libssh2-devel !
I've been working on and off on how libssh2 manages its crypto backends (the end goal being native support for Apple's CommonCrypto), so I started hacking on having a "real" API instead of a bunch of `#define`s (I have a branch that removes the duplicated DH hashing in kex.c thanks to that).
`libssh2_session_init_ex` takes function pointers for memory-management, but there are many offenders (OpenSSL has 7, os400qc3 has 15, WinCNG has 23, you can check using regex `((m|clre)alloc|\sfree)\(`), and this doesn't account for "indirect" uses (the mbedTLS backend uses its own functions, I'd wager most of OpenSSL `*_new` functions do too).
Hence my question is, should I strive to preserve those function pointers and fix those offenders, or would it be acceptable to deprecate those in favor of having more direct `libssh2_(malloc|calloc|realloc|free)` global functions that don't need a `LIBSSH2_SESSION` struct (which is my current problem) ?
I do realize that maybe embedded users of libssh2 have a use for those, or that having those new functions as globals is not a change we want to make. Given the way the current backend macro-API is generally modeled after the OpenSSL quirks^W API, and that its recent incarnations seems to be doing away with having stack-allocation, I'd prefer not to preserve stack-allocating things if it's going away.
Opinions ?
Regards,
Etienne Samson
-- samson.etienne_at_gmail.com _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2017-05-13