From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-59800-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 103880 invoked by alias); 8 Jun 2015 11:24:05 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 103851 invoked by uid 89); 8 Jun 2015 11:24:03 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: mx1.redhat.com
Date: Mon, 08 Jun 2015 11:41:00 -0000
From: Jonathan Wakely <jwakely@redhat.com>
To: Rich Felker <dalias@libc.org>
Cc: Martin Sebor <msebor@redhat.com>, Torvald Riegel <triegel@redhat.com>,
        Szabolcs Nagy <szabolcs.nagy@arm.com>,
        GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] pthread_once hangs when init routine throws an exception
 [BZ #18435]
Message-ID: <20150608112359.GU12728@redhat.com>
References: <556B7F10.40209@redhat.com>
 <556C31DE.4020803@arm.com>
 <556CA772.2060207@redhat.com>
 <1433329427.21461.101.camel@triegel.csb>
 <20150603191444.GM17573@brightrain.aerifal.cx>
 <556F6012.6090502@redhat.com>
 <20150603210031.GN17573@brightrain.aerifal.cx>
 <556F9272.7050405@redhat.com>
 <20150604002122.GO17573@brightrain.aerifal.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20150604002122.GO17573@brightrain.aerifal.cx>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SW-Source: 2015-06/txt/msg00264.txt.bz2

On 03/06/15 20:21 -0400, Rich Felker wrote:
>Is there anything non-conforming about making native_handle() just
>return &this (i.e. considering the C++ object its own native
>primitive)? That seems like the right solution.

As Martin said, it would be completely pointless. If you don't want to
allow access to the underlying primitive then you don't define
native_handle() at all.

>Choice 3 is the utterly worst choice because once an application goes
>down that path, there's no way to extricate the mess and make it
>portable. If you need functionality that the C++ synchronization
>objects don't provide then you need to make your own objects using
>some other primitives, not make assumptions about how the C++ standard
>library's primitives are implemented.

For portable code, yes. But native_handle() is meant for non-portable
uses.