[PATCH] Fix quick_exit to match C++11 specification.

[Adhemerval Zanella]

On 08/06/2016 17:21, Carlos O'Donell wrote:
> On 06/08/2016 03:41 PM, Florian Weimer wrote:
>>> In which case it's only 3 years of usage.
>>
>> Or non-usage. I don't think there are many users. In Fedora rawhide,
>> the only reference is in some auto-generated wrapper code in the
>> smokeqt package.
> 
> This doesn't count the user applications built on top of Fedora
> or other downstream rpm-based distributions though.
> 
> The real complication is that we can't know how many users of a public
> API, and thus once we release the API we generally support it forever.
> 
> There are some cases where we have recently deprecated very very old
> headers, or types, but none of these break backwards compatibility with
> existing applications.
>  
>>>> commit ba384f6ed9275f3966505f2375b56d169e3dc588
>>>> Author: Siddhesh Poyarekar <siddhesh@redhat.com>
>>>> Date:   Mon Feb 18 19:08:21 2013 +0530
>>>>
>>>>     C++11 thread_local destructors support
>>>>
>>>> I don't see how your change makes a different for the libstdc++ approximation.
>>>>
>>>> What am I missing?
>>>
>>> Nothing.
>>>
>>> * Is 3 years enough usage to justify a compat symbol?
>>
>> As I tried to explain, it's unclear where to put the compat symbol.
> 
> In the case of quick_exit, we need only sufficient state such that
> the lower-level exit helpers know now to call thread_local destructors.
> 
> In the case of __cxa_thread_atexit_impl, the new version would need to
> register destructors in another list which is not normally called by
> the code path that quick_exit uses, but is called by the path that
> exit uses. Given that the code to call those lower-level exit helpers
> is all consolidated in one place to reduce duplication, it would be
> more complicated versioning __cxa_thread_atexit_impl.
> 
> However, it is zero complication if we don't versioning anything.
> 
>>> * Is the cost of the compat symbol and long term maintenance
>>>   worth the benefit to our users?
>>
>> I doubt it, every additional symbol makes dynamic linking a tiny bit slower.
> 
> The problem is that a consequence of our failure is the users
> application doesn't work. So we should err on the side of caution.
> 
> Even if additional symbols make dynamic linking a tiny bit slower,
> that's a distinct problem we need to consider solving other ways.
> 
> In summary:
> - I am being conservative by versioning quick_exit.
> - quick_exit is in my opinion the easiest interface to version
>   and logically related to the quick_exit conformance issue with
>   C++.
> - We do need to look at making dynamic linking faster. We might start
>   with: bug 15310, bug 17645.
> 

I personally do not see a compelling reason to provide a compatibility
symbol to standard defined C++11 symbol that explicit states its
interface regarding the offended functionality.  I would see a reason
to add compatibility if the functionality was not defined or if the
interface was not really setted in the time the function was added in
GLIBC.

If the C++11 application is relying on thread_local destruction
for quick_exit, it is a non-conforming one that might only runs correctly
on GLIBC.  I see this as an application issue, not a GLIBC one.