Indeed subsection 19.5.1.3 explicitly says that the comparison operator returns (this == &rhs). That puts standard library implementators in a bind.
It does. You should consider submitting a defect to LWG with the excellent description to wrote in your earlier reply.
Sorry, probably I wasn't clear: I *have* raised this with the committee already, albeit informally. They are well aware of the problems introduced by the use of shared objects on ELF in practice. The problem is that C++ says nothing about shared object binaries. Implicit throughout the standard is the assumption that monolithic binaries are the sole thing ever produced by a linker, period, and in that use case the standard mandated behaviour works perfectly. If you do anything with C++ that is not generating a monolithic executable, you are officially in UB land where monsters such as the problem described lurk. You are *on your own*, and this is despite most C++ programmers are in this UB land on a daily basis. It is unfortunate that the Modules TS intentionally says absolutely nothing about shared binaries. It could have been an opportunity to fix these issues. But objections to that part of earlier proposals was objected to very early, and they got dropped swiftly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/