From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp88.ord1d.emailsrvr.com (smtp88.ord1d.emailsrvr.com [184.106.54.88]) by sourceware.org (Postfix) with ESMTPS id 31EC13857372 for ; Wed, 18 May 2022 17:26:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31EC13857372 X-Auth-ID: tom@honermann.net Received: by smtp20.relay.ord1d.emailsrvr.com (Authenticated sender: tom-AT-honermann.net) with ESMTPSA id 74FBCC00B2; Wed, 18 May 2022 13:26:56 -0400 (EDT) Message-ID: Date: Wed, 18 May 2022 13:26:55 -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: Adhemerval Zanella , Florian Weimer , Adhemerval Zanella via Libc-alpha Cc: Joseph Myers References: <57610f50-dd95-fd32-1102-5f1cda440891@honermann.net> <7c7e07a6-ebf0-71bc-cdc4-2f563b0e3b0f@linaro.org> <87h75ng7ye.fsf@oldenburg.str.redhat.com> <6b3dd2a0-80b9-a1bd-b157-c6f92cdf7fb2@linaro.org> From: Tom Honermann In-Reply-To: <6b3dd2a0-80b9-a1bd-b157-c6f92cdf7fb2@linaro.org> X-Classification-ID: 398ef638-d7c9-40f0-887a-0306b204c2e3-1-1 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 17:26:59 -0000 On 5/18/22 12:17 PM, Adhemerval Zanella wrote: > > On 18/05/2022 12:32, Tom Honermann wrote: >> 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. > Do we need to keep distinct states for each one or can use the a shared > one? Each is required to maintain its own state. The relevant wording from C17 7.28.1 (Restartable multibyte/wide character conversion functions) paragraph 1 states: These functions have a parameter, ps, of type pointer to mbstate_t that points to an object that can completely describe the current conversion state of the associated multibyte character sequence, which the functions alter as necessary. *If ps is a null pointer, each function uses its own internal **mbstate_t**object instead, which is initialized at program startup to the initial conversion state; the****functions are not required to avoid data races with other calls to the same function in this case. The **implementation behaves as if no library function calls these functions with a null pointer for ps.* Tom.