From nobody Tue Sep 20 20:59:48 2022 X-Original-To: freebsd-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 4MXDSy04b6z4cBbv for ; Tue, 20 Sep 2022 21:00:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MXDSx04cWz3LX7 for ; Tue, 20 Sep 2022 21:00:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92f.google.com with SMTP id b7so1590876uas.2 for ; Tue, 20 Sep 2022 14:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=TjHny6pltLxybpPSwkXMbzM75ZbqF7sB7C9xicedHeU=; b=uAkCcYiWi+qV3+jALPYQhWWS2fJDrxO4/0o8uc8ZpspGa96gCcm32yY2kcJvcM/jfQ GI5BFJ98q3xcjdYR2nNZyrCdpKieVKIXfIU5DBfL2GAH+fXz0J8X+ygNBJ6onH4e1K4B 6Kul7tRjaMVTro6KHZMiwL5hGh2toojtmeaZNSzenNLPKOxrB/aOnnmXJpJ9Ou2SVDpK No+TqHR8eHOIOYs3u0+0IQe9gCGPxheY5P7Yj1LyuqkZ0CBZZdhCjpLYM+mez509tSDL MSiCBEylYruUTAbW/htlJ4TRhre608c7E5lsL+l2Saa6wFMfkosdvTirHC56OFw1ybYZ 7sDQ== 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; bh=TjHny6pltLxybpPSwkXMbzM75ZbqF7sB7C9xicedHeU=; b=LSYTnV3BrD8qV8wheMgiSUCYsvqQDov8tKfqPLhzeDzaRKWwBkhFS/mJ5a0U61QfoT 8H/9tzh1vPfuT2J18s41eX2BIXOSKwPVwxONRW7L+471l62Zd3yEB4BXi0rzgu95uaUJ bjUi3KNmfdFc1ssouTgci1Vm3AGs/TwnzAUtiQlkxXMvCvLyOgvRxwHGbDNIKsPuBNSM by7NBaCntJ8WwKPovlAZIer3kBIRtQS3IGXDpkSM9bIQONfvypardIRco4q8O+3fiIY3 ZgORcO8rUy9wKgRsAEigk3mdFo0OQ6shHae8nszpb3PZ4auSf+jS06RF9f1/WYKqR2Kg +UjQ== X-Gm-Message-State: ACrzQf1tn/Pg2Q88lSdmFKF6GxTb9RgOeD9Ric1z+IIY674CVVSn8Q48 KeoZVALXQE05wTn4FlG+B7i+APFXTbjTX3I13a1COGB281c= X-Google-Smtp-Source: AMsMyM6jDCsr8jVf4J8g13zQzglmOpT+nOWeecXLW6ni5Mw9VcPP9GZOSwxSlMNPIZj3jqlUh55sjoSQcYWZBNSHwXU= X-Received: by 2002:ab0:2b05:0:b0:3af:13aa:b107 with SMTP id e5-20020ab02b05000000b003af13aab107mr9497750uar.20.1663707599836; Tue, 20 Sep 2022 13:59:59 -0700 (PDT) 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 References: <20220920153801.wzsrphd2ychvfbgm@mutt-hbsd> <20220920210955.7ee9fd9f@ernst.home> In-Reply-To: <20220920210955.7ee9fd9f@ernst.home> From: Warner Losh Date: Tue, 20 Sep 2022 14:59:48 -0600 Message-ID: Subject: Re: Stlye(9) strengthen statements on not using K&R function definitions To: garyj@gmx.de Cc: Shawn Webb , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000007fb15c05e9221cf7" X-Rspamd-Queue-Id: 4MXDSx04cWz3LX7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=uAkCcYiW; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_TO(0.00)[gmx.de]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92f:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000007fb15c05e9221cf7 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 20, 2022 at 1:09 PM Gary Jennejohn wrote: > On Tue, 20 Sep 2022 11:38:01 -0400 > Shawn Webb wrote: > > > On Tue, Jul 26, 2022 at 10:31:17AM -0600, Warner Losh wrote: > > > Greetings > > > > > > I've posted a review https://reviews.freebsd.org/D35945 which > strengths > > > statements about K&R definitions and declarations: don't use them. > Most of > > > the K&R code has been removed from the tree (ufs being the last > straggler). > > > Future versions of the C standard will remove the K&R definitions and > > > declaration syntax. clang 15 will whine about this construct. > > > > > > The time is ripe to move to language that suggests an outright > prohibition. > > > > > > Comments about language? Make them in phabricator. > > > Comments about the idea? Reply here > > > > FYI: I did notice the other day that less(1) strictly uses K&R. > > > > Yes, but less is under contrib. The K&R purge should be limited to pure > FreeBSD code IMHO. > style(9) has never been about contrib code. less likely will need to update if it wants to keep building on newer compilers, and we'll pickup those changes. Warner --0000000000007fb15c05e9221cf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 20, 2022 at 1:09 PM Gary = Jennejohn <garyj@gmx.de> wrote:
On Tue, 20 Sep 20= 22 11:38:01 -0400
Shawn Webb <shawn.webb@hardenedbsd.org> wrote:

> On Tue, Jul 26, 2022 at 10:31:17AM -0600, Warner Losh wrote:
> > Greetings
> >
> > I've posted a review https://reviews.freebsd.org/D35= 945 which strengths
> > statements about K&R definitions and declarations: don't = use them. Most of
> > the K&R code has been removed from the tree (ufs being the la= st straggler).
> > Future versions of the C standard will remove the K&R definit= ions and
> > declaration syntax. clang 15 will whine about this construct.
> >
> > The time is ripe to move to language that suggests an outright pr= ohibition.
> >
> > Comments about language? Make them in phabricator.
> > Comments about the idea? Reply here
>
> FYI: I did notice the other day that less(1) strictly uses K&R. >

Yes, but less is under contrib.=C2=A0 The K&R purge should be limited t= o pure
FreeBSD code IMHO.

style(9) has never b= een about contrib code. less likely will need to update if it wants to keep= building on newer compilers, and we'll pickup those changes.

Warner
--0000000000007fb15c05e9221cf7--