From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp82.ord1c.emailsrvr.com (smtp82.ord1c.emailsrvr.com [108.166.43.82]) by sourceware.org (Postfix) with ESMTPS id 03BD13856DDA for ; Wed, 18 May 2022 15:32:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03BD13856DDA X-Auth-ID: tom@honermann.net Received: by smtp11.relay.ord1c.emailsrvr.com (Authenticated sender: tom-AT-honermann.net) with ESMTPSA id 050A3A01B0; Wed, 18 May 2022 11:32:09 -0400 (EDT) Message-ID: Date: Wed, 18 May 2022 11:32:09 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 2/3]: C++20 P0482R6 and C2X N2653: Implement mbrtoc8, c8rtomb, char8_t Content-Language: en-US To: Florian Weimer , Adhemerval Zanella via Libc-alpha Cc: Joseph Myers , Adhemerval Zanella References: <57610f50-dd95-fd32-1102-5f1cda440891@honermann.net> <7c7e07a6-ebf0-71bc-cdc4-2f563b0e3b0f@linaro.org> <87h75ng7ye.fsf@oldenburg.str.redhat.com> From: Tom Honermann In-Reply-To: <87h75ng7ye.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Classification-ID: 79e2db13-8542-404b-a7a8-e8c67ab9b5e8-1-1 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2022 15:32:12 -0000 On 5/17/22 5:33 PM, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 17/05/2022 15:12, Joseph Myers wrote: >>> On Tue, 17 May 2022, Adhemerval Zanella wrote: >>> >>>>> +/* This is the private state used if PS is NULL. */ >>>>> +static mbstate_t state; >>>> Although it was done for other convertion interfaces, I wonder if we should >>>> keep supporting this mt-unsafe usage for newer ones. It was not clear from >>> In C23 it's implementation-defined whether the internal state for such >>> functions has static or thread storage duration (see the general >>> introduction to the uchar.h functions). >>> >> Right, so glibc still need to support either mode. > No, I think we can and should switch. Maybe with new symbol versions > (but the same implementation) if we want to play it conservative. > > The intent in POSIX and C has been for a long time that thread-local > state is permitted for these functions, only the wording did not > technically allow it. The phrase was “not required to avoid data > races”. The problem is that it's possible to tell the difference > without data races (with external synchronization). Many libcs already > use thread-local state for these functions, without any apparent ill > effects. I would err on the side of maintaining consistency across these functions for now and then transition them all at once if there is a desire to do so. Tom. > > Thanks, > Florian >