Re: [Boost-users] Compare boost::system::error_category

Subject: Re: [Boost-users] Compare boost::system::error_category
From: Richard Damon (Richard_at_[hidden])
Date: 2017-03-26 22:21:18

On 3/26/17 5:38 PM, Niall Douglas via Boost-users wrote:
>>> 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
>
There is nothing about a shared binary environment that says you are by 
definition in the Undefined Behavior territory. The question becomes is 
the implementation (fully) conforming when generating programs in this 
form. (It can't be UB, as you can generate the problems with a strictly 
conforming program, which by definition can't have undefined behavior) 
There definitely are challenges to being conforming in this environment, 
and the cost to be conforming may be higher than is desired. One 
solution to the issue is that if your shared library include code that 
came about by a 'weak' definition (one that multiple definitions are 
allowed to be generated, but only one placed in the final output), then 
the library needs to be broken into several smaller libraries, were each 
group of weak symbols gets moved into its own shared library, in a way 
the this piece can be match with the same definition from another shared 
library that also was possibly put into its own shared library.

-- 
Richard Damon