From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13555 invoked from network); 7 Feb 2023 01:21:39 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Feb 2023 01:21:39 -0000 Received: (qmail 22490 invoked by uid 550); 7 Feb 2023 01:21:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16336 invoked from network); 7 Feb 2023 01:15:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WYoV8ELf/J+p2Zvmzo1YKDuxIfUNtAeI+bGpLpKNoq0=; b=HdDPuJV/MshsMGncnOB341vyN5KW5jgPLzXG9zcAYTPff3g7cKGEZgZo8RQytUrl74 /e42a7U0fo/g2hBURNCg2Tn6BoPnwOQ3RVMMzXa9jxbgb2Z4md3CN00/+IbenlaAjQhN NKg2oA2er5VRL4M7THws30NGOJ6Wpl95N0IPV1UKRfpY6NMYDChNUIdFbsQ6p6BqTWid FwLpLgvAs/gGU9HBTgIo4IGHGB1jRxmEklfRbNgJfbCwku1X90OPHETqwMneoros3dyk AGb6G493zdUx5U/MytVN1Eu45y3OaROPDqkvJTL8m1lRTQZq+nt8YazCiEtBABE0Hbx6 C2Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WYoV8ELf/J+p2Zvmzo1YKDuxIfUNtAeI+bGpLpKNoq0=; b=DnCbjqKgW/8x0ueh6pI21lucdwEVNKlmVLoBuO2WkGRvgLnGmcjHt4nGcYB3ntWcmD j88isuK38e0Wnsu/ULRjQqySa4zSvlv94P3XJDkM6bXQcn9c7n5Ld26RLClA6NXpDJiS g3SYtPguwK8TxY535j4c+Tg8IFJYhTybadtjiM6gW+wpZYfsHkizkQCtpzzQKCFb44Nb XfGxN/mhJxUQlTKvH13vV4oaMj8wOtrUJb2jMc14a/VoBvdnn34FH4308a6aDUeZSB+o ZNvyIYPXLbo8kIOgPg6OHklV1HhS5ncckgq/c7EPV3Ay3rm6fFxHtoJyHRD5kYYLkxmk sRLw== X-Gm-Message-State: AO0yUKVSQpLWUWLNjP3Ic9SGXwJR6lePBTqo6MCQefC0U+jz+S5a3WxH FdxA6oTGkwnxArfqk+VHA2B4izkcQTczkIaIB5I4NA== X-Google-Smtp-Source: AK7set9td5j7Mz+hvVCW2VHX/1QmZdibJo1fekxfqVdlYfdRp5mXdtD0Uhm7GXHhMPnFRWlkU21rt9jv0a31qe/Bwfo= X-Received: by 2002:a67:c31e:0:b0:3ec:6b3:a05e with SMTP id r30-20020a67c31e000000b003ec06b3a05emr372754vsj.82.1675732522439; Mon, 06 Feb 2023 17:15:22 -0800 (PST) MIME-Version: 1.0 References: <20230204063021.2681891-1-pcc@google.com> <20230205200003.GA1998@voyager> <20230205234930.GM4163@brightrain.aerifal.cx> In-Reply-To: <20230205234930.GM4163@brightrain.aerifal.cx> From: Peter Collingbourne Date: Mon, 6 Feb 2023 17:15:08 -0800 Message-ID: To: Rich Felker Cc: Markus Wichmann , musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] [PATCH] arm: Use __WCHAR_TYPE__ for wchar_t if defined On Sun, Feb 5, 2023 at 3:49 PM Rich Felker wrote: > > On Sun, Feb 05, 2023 at 09:00:03PM +0100, Markus Wichmann wrote: > > On Sat, Feb 04, 2023 at 08:08:36AM +0100, alice wrote: > > > On Sat Feb 4, 2023 at 7:30 AM CET, Peter Collingbourne wrote: > > > > When building with -fshort-wchar the definition of wchar_t is > > > > incorrect. Get the correct definition from the compiler if available. > > > > > > > > This is useful when reusing the freestanding parts of musl on a > > > > bare-metal target that uses -fshort-wchar. > > > > > > somebody talked about this in 2015, see > > > https://www.openwall.com/lists/musl/2015/02/18/2 > > > for the previous discussion. > > > > > > i understand in this case it's proposed a little different- > > > "reusing freestanding parts" as opposed to building a whole libc.so, but in > > > that case you could most likely patch this in when reusing it standalone only? > > > > > > it doesn't seem a good idea for it to be there, in general. > > > > Seconded. A lot of code in musl depends on wchar_t being able to hold > > the current maximum Unicode codepoint of 0x10FFFF at least, so the type > > must be at least 21 bits. > > Absolutely. -fshort-wchar requests a different ABI that is > fundamentally incompatible with libc and with use of the libc headers, > and also fundamentally incompatible with Unicode and the requirements > of the C language (unless you only want to support the BMP) -- C does > not allow "multi-wchar_t characters". > > If you're targeting freestanding environment not using libc, you > should use -nostdinc and provide headers suitable to your environment > instead of the libc ones. But really you should fix the offending code > not to use wchar_t for UTF-16, and not use -fshort-wchar. Modern C has > a char16_t type for this purpose. Thanks, I agree with this and the other replies that I got. It did seem at first that musl could be used unmodified in projects that build with -fshort-wchar, but given the implications of a UTF-16 wchar_t for the code that implements , it makes more sense for this flag to be unsupported by musl and for any utilizing projects to be fixed to not require -fshort-wchar. Currently we accidentally "support" -fshort-wchar on architectures that happen to use __WCHAR_TYPE__ to define wchar_t. Would it make sense to add something like a static assert to alltypes.h that checks that sizeof(wchar_t) >= 4? Peter