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=-10.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21481 invoked from network); 7 Nov 2021 17:37:52 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Nov 2021 17:37:52 -0000 Received: (qmail 5690 invoked by uid 550); 7 Nov 2021 17:37:48 -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 5657 invoked from network); 7 Nov 2021 17:37:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zF6VLBB1zgIMj7Tr3fUFH/8fvmT+HagKBR4vXR/L5yY=; b=ghOY9UzN5h/wVwkRNbgsuCLO8BjbkXrpKLV+TPXhXL/ij4yGw8f0khZCfLRL1fCzCJ S9QikPcCXf+TdseVfaE5BG3uOE73ZHTQ3I+o8kl7d39TelTiiIEDzj03IdtoGXkQesHb H295+aOSsYXD4mcl6iz8liEu3y2oiAm88C8hkGneuOQ226ujZFe7kdX76tfviJpcN7Lr GCDOWFc/7bpEm5l2L5eWzo8SvT2np6HVqXWj4Z/MJYVywDDHl6paSLyYvTHdIfZ1plqm gXKQDTRm5OXmrMRSqjcR+Jn6usB+djYKum1vzqKEwuaBZG8hVQ1roodgRhCkCJmaPQYm EkNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zF6VLBB1zgIMj7Tr3fUFH/8fvmT+HagKBR4vXR/L5yY=; b=yzRtoO0vJmBa8yJXRrg8lUkDbOyebNqH4XJaEcPGcApD6ddg9ApFwhIVrq0bvsFY67 s11u+WttmMjfCnwhM90fo6rcpHboq2GLCz3y9hxNaMW+B1N5HsqsUSkVlkgottnribGB Ogsu79TK8AZiVJls3AeZwsDNAzlsGx9IRS5Zx3dfZaJZ9BNn7Q+MxsVa05WRt9wALKF5 SPZVCHr4fwuy/RIIudeBp8LkGTfTf3AySqK1zmdhj1h1TqLkPN8zr+/Cmxo7mICxz0CP WF717lWvy/D4TqBn62cG3RJ8qf2P1tzxBQgU/64qS+taVdpB/joOhJ7gQQDtVpyj01kL QyFw== X-Gm-Message-State: AOAM532XN0pk01O2IaQFdO/6aM3EAgQduROS+Pe3RCeNY0CL7W4J8ldc sxkZR5OApgYlOqXHXNpblt5ZCx1XZQLQvDRI+ISrhuQPM04= X-Google-Smtp-Source: ABdhPJzQX0zwKJOm2hdks6QiXtZp+4YXJ6Ly4nV1G8ZNNYStn39oHxGjwD0e3bShl8n7tQs7Yg2KEIm9F7zyGhMEdjQ= X-Received: by 2002:a05:6512:3416:: with SMTP id i22mr6929640lfr.4.1636306655780; Sun, 07 Nov 2021 09:37:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: James Y Knight Date: Sun, 7 Nov 2021 12:37:09 -0500 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000f6d13205d0365458" Subject: Re: [musl] add noexcept to all functions please --000000000000f6d13205d0365458 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 6, 2021 at 2:40 PM Joakim Sindholt wrote: > On Sat, Nov 06, 2021 at 06:28:31PM +0000, Jon Chesterfield wrote: > > That's a compiler bug, surely. A C function that takes no callbacks is > not > > going to throw. > > I don't think the compiler can prove that. As far as I know the extern > "C" {} that C headers get wrapped in for C++ just means the compiler > doesn't type-mangle function names. The function itself can not only > throw by itself but it can also call other functions that throw as part > of its implementation. That's correct. In general, extern "C" functions are allowed to throw. > If there's a compiler bug here it would have to be that it discards > knowledge about C standard functions that can indeed not throw. I don't > know if that's the case here, or if it's just nonstandard functions that > are affected. Some of the common standard functions are detected and treated specially by compilers. Such libc functions that have special-casing are already generally treated as non-throwing by both GCC and Clang. However, there are a _lot_ of libc functions, both standard and nonstandard, that the compiler doesn't hardcode any knowledge about. > FWIW I don't think musl should tag any functions with anything just to > make C++ marginally faster. This seems like a case of C++ getting > hoisted by its own petard. > I have no horse in this race, but that really seems not a very helpful attitude. There's a large number of users of libc who are using C++ rather than C -- and many (most?) of them are compiling with exceptions enabled. If adding minor cruft to all of the libc function declarations will make a meaningful difference to all of that code's performance, that seems well worth considering, regardless of anyone's opinions regarding decisions about how to implement exceptions in C++ that were made 30 years ago. Glibc defines macros for this purpose, which expand into "throw()" in C++ and "__attribute__((__nothrow__))" in GCC-C. The latter is only useful in conjunction with an extremely-rarely-used feature, C code built with -fexceptions enabled, and is thus probably ignorable. --000000000000f6d13205d0365458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 6, 2021 at 2:40 PM Joakim Sin= dholt <openso= urce@zhasha.com> wrote:
On Sat, Nov 06, 2021 at 06:28:31P= M +0000, Jon Chesterfield wrote:
> That's a compiler bug, surely. A C function that takes no callback= s is not
> going to throw.

I don't think the compiler can prove that. As far as I know the extern<= br> "C" {} that C headers get wrapped in for C++ just means the compi= ler
doesn't type-mangle function names. The function itself can not only throw by itself but it can also call other functions that throw as part
of its implementation.

That's correct. = In general, extern "C" functions are allowed to throw.
= =C2=A0
If there's a compiler bug here it would have to be that it discards
knowledge about C standard functions that can indeed not throw. I don't=
know if that's the case here, or if it's just nonstandard functions= that
are affected.

Some of the common standard f= unctions are detected and treated specially by compilers. Such libc functio= ns that have special-casing are already generally treated as non-throwing b= y both GCC and Clang. However, there are a _lot_ of libc functions, both st= andard and nonstandard, that the=C2=A0compiler doesn't hardcode any kno= wledge about.
=C2=A0
FWIW I don't think musl should tag any functions with anything just to<= br> make C++ marginally faster. This seems like a case of C++ getting
hoisted by its own petard.

I have no ho= rse in this race, but that really seems not a very helpful attitude. There&= #39;s a large number of users of libc who are using C++ rather than C -- an= d many (most?) of them are compiling with exceptions enabled. If adding min= or cruft to all of the libc function declarations will make a meaningful di= fference to all of that code's performance, that seems well worth consi= dering,=C2=A0regardless of anyone's opinions regarding decisions about = how to=C2=A0implement exceptions in C++ that were=C2=A0made 30 years ago.

Glibc defines macros for this purpose, which expand= into "throw()" in C++ and "__attribute__((__nothrow__))&quo= t; in GCC-C. The latter is only useful in conjunction with an=C2=A0extremel= y-rarely-used feature, C code built with -fexceptions enabled, and is thus = probably ignorable.

--000000000000f6d13205d0365458--