From owner-svn-src-head@freebsd.org Sat Dec 19 14:58:56 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F2764C9E9C; Sat, 19 Dec 2020 14:58:56 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 4Cyplg6xbZz3pwL; Sat, 19 Dec 2020 14:58:55 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 5742116058; Sat, 19 Dec 2020 15:58:54 +0100 (CET) Date: Sat, 19 Dec 2020 15:58:53 +0100 From: Steffen Nurpmeso To: Konstantin Belousov Cc: Kevin Bowling , Ian Lepore , Jessica Clarke , Mateusz Piotrowski <0mp@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r368714 - head/lib/libc/string Message-ID: <20201219145853.pLBGG%steffen@sdaoden.eu> In-Reply-To: References: <202012171241.0BHCfl1r008452@repo.freebsd.org> <686CF2E6-1D3C-4A83-A323-02CD9F536675@freebsd.org> <452cbb1060b7134315999c2323ed431714dc03fe.camel@freebsd.org> <20201219135225.B6y3g%steffen@sdaoden.eu> Mail-Followup-To: Konstantin Belousov , Kevin Bowling , Ian Lepore , Jessica Clarke , Mateusz Piotrowski <0mp@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org User-Agent: s-nail v14.9.20-84-g7268a84d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Cyplg6xbZz3pwL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 14:58:56 -0000 Konstantin Belousov wrote in : |On Sat, Dec 19, 2020 at 02:52:25PM +0100, Steffen Nurpmeso wrote: |> Kevin Bowling wrote in |> : |>|On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote: |>|> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote: |>|>> On Thu, Dec 17, 2020 at 01:01:01PM +0000, Jessica Clarke wrote: |>|>>> On 17 Dec 2020, at 12:53, Konstantin Belousov |>|>>> wrote: |>|>>>> On Thu, Dec 17, 2020 at 12:41:47PM +0000, Mateusz Piotrowski |>|>>>> wrote: |>|>>>>> Author: 0mp (doc,ports committer) |>|>>>>> Date: Thu Dec 17 12:41:47 2020 |>|>>>>> New Revision: 368714 |>|>>>>> URL: https://svnweb.freebsd.org/changeset/base/368714 |> ... |>|>>>>> + return (0); |>|>>>> |>|>>>> return (0) is redundand. |> ... |>|>> Why it is bad practice ? |>|>> |>|>> C is a small language, and while knowing some quirks (like this one) |>|>> seems to be optional, others are not. And worse, that other quirks a= re |> ... |>|> How obscure is this quirk? I've been writing C code since 1983, |>|> including having released a freeware compiler (pre-gcc days) and |>|> working on a commercial C compiler. I used to moderate the c_language |>|> conference on BIX (back when that was a thing). I make my living |>|> writing C and C++ code every day. And yet, I had completely forgotten |>|> about this quirk. |> ... |>|In Kib=E2=80=99s defense I think this is commonly mentioned in C99 book= s \ |>|(at least |>|that=E2=80=99s where I learned of it) so it depends on when and where s= omeone |>|learned. There are merits approaches of being explicit or brief. I ha= ve |>=20 |> Nicely said. K&R C 2nd Ed. explicitly uses return(0) many times. | |We are long after K&R in any of its form. | |My point was that the example if of very low quality, and return (0); is |an indicator. Perhaps even more interesting point to make is the mix of |return from main() and exit(3) use in same 4 lines. Besides inconsistenc= y, |exit(3) from main() should probably not used in examples or recommended |to novices at all. I .. cannot see this from the context above? I personally use _?exit only if execution must not continue aka control cannot be given back to code flow. For me .. not. C89 can be used here. (It is annoying only for field initializers, and there especially that the order must be correct in C89 mode, when FIELD_INIT[IN]() expands to nothing.) (Yes, one of the things i personally was out for was restartability without leaks for at least development, ie, it was only "fine" if one could have entered sf_main() multiple times without causing problems. This required "atexit_uninstall" and two distinct priorities for exit handlers, and a clean order of the "final" ones, also atcrash_uninstall, but it was nice to see "SF: memcache empty!" messages in debug code, knowing it is nice. Today i only do this a bit as i link other libraries anyway, and everybody uses ctors and dtors and it is all dynamically linked, .. and all that.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)