From nobody Wed Oct 27 05:11:13 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 DABB51812CE6 for ; Wed, 27 Oct 2021 05:11:21 +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 4HfGxj3wn3z3hTf; Wed, 27 Oct 2021 05:11:21 +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 19R5BDoC061587 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 08:11:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R5BDoC061587 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R5BDFX061586; Wed, 27 Oct 2021 08:11:13 +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 08:11:13 +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: 4HfGxj3wn3z3hTf 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:49:58PM -0700, Gleb Smirnoff wrote: > On Wed, Oct 27, 2021 at 07:39:38AM +0300, Konstantin Belousov wrote: > K> > K> Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. > K> > > K> > You actually can return void to hint compiler for a tail call optimization. > K> > It is not a wrong syntax. > K> > > K> > Other code that is working with true void functions (e.g. with WITNESS) and > K> > doesn't work with "do {} while" is: > K> > > K> > void > K> > something(bool clue) > K> > { > K> > return (clue ? rw_rlock(lock) : rw_wlock(lock)); > K> > } > K> > > K> > This is explicitly allowed in 6.5.15 of the C11 standard. > K> > > K> > Of course all this code can be written in some other way, so constraint > K> > of KPI not being true functions can be worked around, but I believe better > K> > it be fixed. > K> > K> Hum. I know about ternary operator allowing void-typed expressions on both > K> sides of ':'. What I replied to is the following, from C17 > K> > K> 6.8.6.4 The return statement > K> Constraints > K> 1 A return statement with an expression shall not appear in a function > K> whose return type is void. A return statement without an expression > K> shall only appear in a function whose return type is void. > K> > K> So syntax above is explicitly prohibited by the standard. I was quite > K> surprised that both gcc and clang silently accept this, unless -pedantic > K> is specified. There is no mention of this extension in gcc manual. > K> Compiler explorer demonstrates that compilers like msvc do warn about > K> the construct, and some even error out (tendra): > K> https://godbolt.org/z/xqcPssTcY > K> > K> Another part of the confusion, perhaps, is that > K> return ; > K> is explicitly allowed by the C++ standard (I looked at 2020 version), > K> unlike C. > > Hmm, so I mistakenly transferred my knowledge about the tail call > optimization hint from C++ to C. > > Okay, let's put return aside. This would compile with true > functions (e.g. WITNESS), otherwise not: > > void > something(bool clue) > { > clue ? rw_rlock(lock) : rw_wlock(lock); > } > > And this is correct code per 6.5.15. So why cannot you write it as ... if (clue) rw_rlock(lock); else rw_wlock(lock);