References https://zeromq.jira.com/browse/LIBZMQ-450 :
"Adrien Kunysz added a comment - 16/Nov/12 11:45 AM
As per previous comment. I am still able to reproduce the issue after applying the patch."
[LIBZMQ-450] Copy the stream engine endpoint - string reference cause…
…d memory corruption
Looks good, but might be an idea to replace the strcpy with strncpy
I think this does not solve the problem. The whole engine, along with the address buffer, can be deallocated before the user app can read the notification message. I would suggest to copy the address into that notification message.
Revert "Merge pull request #473 from methodmissing/fix-engine-endpoint"
This reverts commit 1a18c7b, reversing
changes made to bef9a41.
Reworked in https://github.com/methodmissing/libzmq/compare/copy-monitor-endpoints
You are allocating memory using new, so the consumer should use  delete to release the memory. What if the application uses C or Java binding? Also, when the application closes the notification socket, it needs to be sure there is no message ready to be received. Otherwise the application will leak memory.
What about using multi-part messages to transfer events - one message part per field of notification structure.
Another option is to embed a fixed size array in the event structure and pass copy of endpoint address rather than pointer to copy of endpoint address. The obvious difficulty is how to choose the size of that array.
Perhaps we should move the discussion to ML.
I had time to briefly scan Martin's feedback before boarding for a flight yesterday and spent that time extracting a symmetric message oriented API that requires the consumer to explicitly free any events :
Shall I summarize recent changes for context and we resume this discussion on the ML ?
Another option is to initialise event messages using msg_t::init_data method. That way, you may create a temporary buffer in the library holding the endpoint's address and pass a function that frees that buffer to init_data. Once the user closes the received event message, the library will free the buffer's memory. This way we do not need to extend the current API.
As for failures, it depends on memory allocator in use, I think.