From nobody Wed Oct 27 04:39:38 2021 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 43530182F28B for ; Wed, 27 Oct 2021 04:39:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfGFH3xP2z3Jlm; Wed, 27 Oct 2021 04:39:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19R4dclQ052998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 07:39:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R4dclQ052998 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R4dc0M052997; Wed, 27 Oct 2021 07:39:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2021 07:39:38 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HfGFH3xP2z3Jlm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 26, 2021 at 09:17:27PM -0700, Gleb Smirnoff wrote: > On Wed, Oct 27, 2021 at 05:06:52AM +0300, Konstantin Belousov wrote: > K> > counters. > K> > K> That said, you seems to use wrong syntax for your example. Might be, it > K> is enough to fix that, and not change the definition? > K> > K> void > K> something(bool clue) > K> { > K> if (clue) { > K> rw_rlock(lock); > K> else > K> rw_wlock(lock); > K> } > K> Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. > > You actually can return void to hint compiler for a tail call optimization. > It is not a wrong syntax. > > Other code that is working with true void functions (e.g. with WITNESS) and > doesn't work with "do {} while" is: > > void > something(bool clue) > { > return (clue ? rw_rlock(lock) : rw_wlock(lock)); > } > > This is explicitly allowed in 6.5.15 of the C11 standard. > > Of course all this code can be written in some other way, so constraint > of KPI not being true functions can be worked around, but I believe better > it be fixed. Hum. I know about ternary operator allowing void-typed expressions on both sides of ':'. What I replied to is the following, from C17 6.8.6.4 The return statement Constraints 1 A return statement with an expression shall not appear in a function whose return type is void. A return statement without an expression shall only appear in a function whose return type is void. So syntax above is explicitly prohibited by the standard. I was quite surprised that both gcc and clang silently accept this, unless -pedantic is specified. There is no mention of this extension in gcc manual. Compiler explorer demonstrates that compilers like msvc do warn about the construct, and some even error out (tendra): https://godbolt.org/z/xqcPssTcY Another part of the confusion, perhaps, is that return ; is explicitly allowed by the C++ standard (I looked at 2020 version), unlike C.