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

Subject: Re: [Boost-users] Compare boost::system::error_category
From: Christopher Pisz (christopherpisz_at_[hidden])
Date: 2017-03-25 23:05:32

What would be so wrong with category being an actual number to compare
against?

I don't know anyone whom creates classes and operator == using the address
of that class. You guys talk about the standard and what not, and
admittedly I've never looked inside how they implement things, but I've
never had such problems using the STL either.

On Sat, Mar 25, 2017 at 5:58 PM, Boost - Users mailing list [via Boost] <
ml-node+s2283326n4692952h86_at_[hidden]> wrote:

> >>>> Boost's quality of implementation is the same as libstdc++ or libc++,
> >>>> you can get multiple instantiations in certain circumstances and
> those
> >>>> can have differing addresses.
> >>>
> >>> The various error categories are implemented (for header-only
> libraries)
> >>> as inlined Meyer singletons. Does that mean that we have a general
> >>> problem with such singletons?
> >>
> >> The short answer is yes, the error category comparison operators are
> >> unreliable on all major STLs apart from Dinkumware's and in Boost.
> >
> > Can you elaborate on what the core problem is?
>
> To generate ELF object A using header only library X which defines a
> custom error category, the linker chooses any one of the implementations
> of that error category in the object files linked as it is marked weak
> due to being inline. Due to use of -fvisibility=hidden, symbol for
> custom error category is not exported.
>
> To generate ELF object B using header only library X which defines a
> custom error category, the linker chooses any one of the implementations
> of that error category in the object files linked as it is marked weak
> due to being inline. Due to use of -fvisibility=hidden, symbol for
> custom error category is not exported.
>
> Program C links against ELF object A and ELF object B. There are now two
> instances of the same category object, and their addresses will not
> equal. Possible solution: Mark custom error category retrieval function
> with default visibility?
>
> That will work with RTLD_GLOBAL. But what if a SO is loaded with
> RTLD_LOCAL? That establishes multiple global symbol tables, and once
> again two instances of the same error category appear.
>
> The exact same problem applies to the RTTI used to catch exception
> throws. The problem was fixed on libstdc++ by using string comparison to
> compare RTTI if address comparison failed. libc++ used to noisily take a
> stand against string comparison and insist on address comparison, but
> they may since have buckled under the constant bugs about exceptions not
> being caught.
>
> > You have mentioned both memory barriers and RTLD_LOCAL which seem to
> > imply different problems (concurrency versus relocation of weak
> > symbols.)
>
> MSVC has the advantage of controlling its ABI. They invented a thing
> called _Immortalize which gets specially treated by the linker to
> instantiate exactly one of the thing ever in a process. As the VS2015
> source file says, /* MAGIC */. Because multiple threads could reach the
> instantiation concurrently, it needs to be a memory barrier so one gets
> chosen and the others wait.
>
> > Please notice that I am interested in singletons in general, not only
> > error categories.
>
> PE and MachO are the least affected by this problem because their
> creators thought of symbol encapsulation in advance. ELF is severely
> affected by it. The fault is in the ELF spec which assumes a globally
> visible unique symbol table. I have tried raising this problem with
> those responsible for ELF on a number of occasions in the past, it was
> considered not a problem for the linker and ELF folk, they felt it was a
> C++ problem. Attempting to explain this was not a problem in PE nor
> MachO nor many other binary formats got me nowhere.
>
> Niall
>
> --
> ned Productions Limited Consulting
> http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
>
> _______________________________________________
> Boost-users mailing list
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=4692952&i=0>
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://boost.2283326.n4.nabble.com/Compare-boost-system-error-category-
> tp4692861p4692952.html
> To unsubscribe from Compare boost::system::error_category, click here
> <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4692861&code=Y2hyaXN0b3BoZXJwaXN6QGdtYWlsLmNvbXw0NjkyODYxfC04ODIyNjQ5NzI=>
> .
> NAML
> <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--
View this message in context: http://boost.2283326.n4.nabble.com/Compare-boost-system-error-category-tp4692861p4692953.html
Sent from the Boost - Users mailing list archive at Nabble.com.