[libcxx-commits] [PATCH] D65667: [libcxx] Early-initialize error_category singletons

[Marshall Clow via Phabricator via libcxx-commits]

mclow.lists added a comment.

In D65667#1617952 <https://reviews.llvm.org/D65667#1617952>, @thakis wrote:

> To chime in from the sidelines: We strive to have zero code that runs before main in Chromium, so we're not excited about a patch that adds more such code to libc++. (In fact, we're hoping to contribute a build mode that removes the existing static initializer for cin/cout/cerr as well.)


I'll pass along a comment from Howard (made to me privately, but he agreed that I could share it here):

> There's a FILO guarantee on lifetime here: http://eel.is/c++draft/basic.start.term#3
> 
> A careful client would take advantage of that guarantee by ensuring that the lifetime of the object returned by std::generic_category() starts before the lifetime of a. One easy way to do this is in the default constructor for A:
> 
>   A() {std::generic_category();}
> 
> Failure to go to such effort is where the UB lies.   The suggested "fix" which attempts to remove this responsibility from this client imposes a cost on every other client of libc++, whether or not one uses <system_error>.  The more namespace-scope static objects there are in libc++, the longer it takes every program that links to libc++ to launch and reach main().  Apple considered this such a large problem that they forbade namespace-scope static objects  and I had to get special permission for the std streams: `cin`, `cout`, etc.
> 
> Not only would acceptance of this patch penalize all users, it would still not absolutely guarantee a fix.  Platforms are free to initialize namespace-scope objects in main prior to initializing namespace-scope objects within libc++.


Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65667/new/

https://reviews.llvm.org/D65667