From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 282283858C52 for ; Wed, 18 May 2022 16:17:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 282283858C52 Received: by mail-oi1-x231.google.com with SMTP id q8so3199121oif.13 for ; Wed, 18 May 2022 09:17:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3KiQoh7hc5Z7YfEF9EC05WFcKuyMeB5LvDj3N1VbkJM=; b=ulRK8VG1t70jtMbrC8a/wZnGT3sIXXSqbfogJDib1l96YxKVIo+RTXXoEE6Eg5CSlt peDWDYXyjhN0sizOSNDzNsv5bzmoMzQtv3kdkVq7tWgbTtZcNj+3RiRT5AMj/SxYnG1X MuBZ7elHL7TwLueQlqX52PqtWwoJZuZUTLiKWI/mKnlAoo3RStnvyyKotV60H8bFlXlc 9vpqa5dCwMZ/TudyTcn58yfDj+TFqQtfDp2ahbM0gaEUW0ZR7PULJ8t4sC6IMYj39iFi aJro7XueIEGzZPen5t0dE0XKnMFGOPQ1/2tyvRyQzWAZisZl5GwKYvLlXtGA+0imM3pq 2aeA== X-Gm-Message-State: AOAM530h5snG3v0lgfyKHbncusebbPG0I6Q35alUZP10LdLmvhNhj5Qe Frpa4ah0MAc/OK09HRUjNvJOf5VA9INiWg== X-Google-Smtp-Source: ABdhPJxIS2UzQ4R/2uMinbeR+IFzVhF+6dxBUQENTncv+bUGKKL7IDIangyM3D9zn+EW0l0VBGPsjQ== X-Received: by 2002:aca:d8c5:0:b0:325:e353:a6b9 with SMTP id p188-20020acad8c5000000b00325e353a6b9mr209358oig.135.1652890661472; Wed, 18 May 2022 09:17:41 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:cdd6:1a62:669c:7cd2:ac43? ([2804:431:c7cb:cdd6:1a62:669c:7cd2:ac43]) by smtp.gmail.com with ESMTPSA id k22-20020a056870959600b000e686d1386asm1239589oao.4.2022.05.18.09.17.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 May 2022 09:17:40 -0700 (PDT) Message-ID: <6b3dd2a0-80b9-a1bd-b157-c6f92cdf7fb2@linaro.org> Date: Wed, 18 May 2022 13:17:37 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 2/3]: C++20 P0482R6 and C2X N2653: Implement mbrtoc8, c8rtomb, char8_t Content-Language: en-US To: Tom Honermann , 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> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 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 16:17:44 -0000 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?