I need to understand how things work here before I can consider suggesting using this library. I sent mail to this list proposing to add SAL annotations to the codebase in phases, and the feedback I got was that it was welcome. The subsequent PR got a few laconic comments that were not much aligned with what I’d consider to be respectful and constructive feedback. For example asking me to “go ask the owner” of this “proprietary tool” - which is actually a compiler feature - to “make it work without needing to make a mess” after stating that they “would not read anything” as far as the related documentation is not the kind of feedback I expected. I need to convince myself that this community is still 1) welcoming new contributors and 2) keeping an open mind with regards to the evolution of the codebase. As it stands, I see two major adoption blockers as far as I’m concerned: a) There is no way to demonstrate correctness of both API usage and internal implementation. For example zmq::ip_addr_t zmq::ip_addr_t::any (int family_) happily returns uninitialized memory if passed an invalid parameter. SAL is meant to catch those (and much more) at compile time. b) The library takes on itself to terminate the process on runtime errors where it should never (like out of memory) and fail to terminate it on obvious programmer errors like the one above. In some contexts, a library terminating its calling process on runtime errors is a strict no-no. For example, a caller may elect to retry on ENOMEM after shrinking a cache or something. Anecdotally, using printf (which may allocates memory) to indicate an out of memory condition is also revealing of opportunities for improvement. I need to be sure that I can solve a) and b) and other potential blockers to a reasonable extent before investing more time on this project. Thoughts? —Axel
|
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
