From nobody Tue Nov 21 00:44:56 2023 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 4SZ5J71QwHz51P2R for ; Tue, 21 Nov 2023 00:45:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4SZ5J55SWYz4YJY for ; Tue, 21 Nov 2023 00:45:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=N9KUijME; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52f) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5446c9f3a77so7286910a12.0 for ; Mon, 20 Nov 2023 16:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700527508; x=1701132308; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JDc6mZ3wFxmMsDzCkZw9fiUL//nxfAAtWPUeLaAaHfI=; b=N9KUijME3whvtuMc+ZgmYLVTPe8i+a7uCVuaxwY+VF29TXexlQoazZckO3Jiw6bTOO etbBSM6lqrHdu/JBlvtJ6vgt6nqJ4yIU8PHTlRmun9O1/d9MLjMchSXmAbdhgROzvRFC pR2xXk1pcRi0JlpBqIfp4APOGBu3j6QZKxHrIi3M4rIVY753GCdiZVO1jPNrnn9txVku qZBYlp0ZYgnUHPwHaL9IggEnuhorYCPetgcoNoz+pO0OC2tJfNqMwf64oub81kYIxHZK uWLMCjDraQeqS6es7bltc9M70MI3f9CnTI1Lrar9yOeiwbWvWDgXQmqmSKximBCunqeT Cl4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700527508; x=1701132308; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JDc6mZ3wFxmMsDzCkZw9fiUL//nxfAAtWPUeLaAaHfI=; b=DOrGVL2eq1KrSQpyTKgOjnhpbxNHZ7DTd2lRpc6Wr50jC1HJs/qSTzw2Y5YDmXItyP fSfPiDWgpRPBV6jpz64NYcfnpIlf4IEPcxmXLte+hzhhGIHCyJZ7U0g6TLCigDgdSkeG Y5Wa+aWhzOmqUIiLWm9nPdw8C4QZqc63AJSkvKt3fP///Ght5uz/xtudII1WBwJW37Ay /VJhonGA2NYqGIEROdVa0IbgVVfHSbzALHyBzj/aINQr9IAGdExeISYr2eYd9fFCrUhX oGQg2Tz9utNcTzoDQWCLmu56CGMlgGyW/u6msrjUH3laoe8/w/tRMPyQvN0wfG/nK4lM 5lVA== X-Gm-Message-State: AOJu0YwYTyz1Bwp9YnQGFQEj5DJ2cdb15QK8xO6j00bqep7+t4C07WcA Cg0EhQ+bsOb7z/Ghg6gAXHwz+TMQLCsrFHOjLkACou6Ug3TPdadxdCE= X-Google-Smtp-Source: AGHT+IFW4UKGH3kCQ1CwgJIBXmv93TQp1aKcSN/07KDmGbLwE4nJBMw9E5kmFydsoadlf7HcvYvayo0nRTW2xF8eRew= X-Received: by 2002:a50:9518:0:b0:540:4b90:3dc3 with SMTP id u24-20020a509518000000b005404b903dc3mr693219eda.14.1700527507755; Mon, 20 Nov 2023 16:45:07 -0800 (PST) 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: <20231120080109.34bb47d6@slippy> In-Reply-To: From: Warner Losh Date: Mon, 20 Nov 2023 17:44:56 -0700 Message-ID: Subject: Re: Some K&R support to be removed from sys/cdefs.h To: Cy Schubert Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000007e54f060a9eeacb" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4SZ5J55SWYz4YJY X-Spamd-Bar: -- --00000000000007e54f060a9eeacb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 20, 2023 at 9:14=E2=80=AFAM Warner Losh wrote: > > > On Mon, Nov 20, 2023, 9:01 AM Cy Schubert > wrote: > >> On Sun, 19 Nov 2023 20:44:49 -0700 >> Warner Losh wrote: >> >> > Greetings, >> > >> > I've had a long-term background project of cleaning up cdefs.h. So far >> it's >> > all been things that are definitely unused. My next target are some >> > specialized macros used to share code between K&R and ANSI-C compilers= . >> K&R >> > support in general will remain unchanged by this (any code using these >> > macros that wants to continue will need to arrange for that in their >> build >> > system). It may surprise many to learn with about 30 flags on the >> command >> > line, one can compile unmodified code from the 80s that conforms to th= e >> V7 >> > K&R language spec (for some not terrible definition of conforms to a >> > squishy spec). >> > >> > The support I'm talking about is __P, __CONCAT, __STRING, defining >> __const, >> > __inline, __signed and __volatile to nothing (only on some compilers) >> and >> > sometimes defining const, inlined, signed and volatile to nothing when >> > building when __STDC__ is not defined. This support was a transition >> from a >> > time, predating the FreeBSD project for the most part, when numerous >> > programs were specially curated so they could build on K&R compilers a= s >> > well as the then newly emergent ANSI-C compilers that were appearing. >> The >> > need to do this has long since past, so I'll be removing the pre-ansi-= c >> > build environment support for doing this specific thing. >> > >> > I'll retain __P, __const, __signed and __volatile in __STDC__ >> environments, >> > but have firm plans to remove them completely in a future round. I've >> > already removed all __P usage from the tree (except sendmail). The >> others >> > have a smattering of long-dead-hand-of-the-past usage in the tree (in >> libm, >> > for example). I plan on leaving __inline unchanged because it has a >> > secondary meaning. I suspect the only wide-spread one that will cause = me >> > grief is __P. All the others I see occasionally, but it's not pervasiv= e >> > like __P once was (and still is in older projects, shocking at that ma= y >> be). >> > >> > I have no plans on eliminating __CONCAT or __STRING. Their use is >> > widespread in the tree is extensive, and where they are used, it's fin= e. >> > There's no need to gratuitously churn things here. To the extent that >> pure >> > K&R compilers are including our system headers, this will represent on= e >> > more tiny step away from supporting that (as they are used in our >> headers). >> > But such environments need their own headers anyway: all our headers u= se >> > ANSI-C prototypes w/o __P protection. >> > >> > As with all my cdefs cleanups, I'll do exp runs before I commit. For t= he >> > more consequential ones, I plan on posting reviews. For the other >> myriad of >> > completely unused and designed to tell gcc3 from gcc4 or gcc2 from gcc= 3, >> > I'm just going to eliminate those.There's no point in keeping them onc= e >> I >> > make sure nothing in ports uses them. >> > >> > I suspect nobody will care, except to cheer on the removal of >> > no-longer-needed junk that makes cdefs.h hard to read. My timeline for >> this >> > and other cleanup of cdefs.h is 'before 15 branches'. >> > >> > Comments? Suggestions? >> > >> > Warner >> >> Would we need an exp-run to find ports that might need some attention? >> > > Need? No. There's nothing that will break. > > Will I do it anyway? Yes. "Can't fail" changes to this file has burnt me > in the past... > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275221 has the exp run queued up. And the changes if people want to look. Warner > Warner > > > -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: https://FreeBSD.org >> NTP: Web: https://nwtime.org >> >> e^(i*pi)+1=3D0 >> > --00000000000007e54f060a9eeacb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 20, 2023 at 9:14=E2=80=AF= AM Warner Losh <imp@bsdimp.com>= wrote:


On Mon, Nov 20, 2023, 9:01 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote:
On = Sun, 19 Nov 2023 20:44:49 -0700
Warner Losh <imp@bsdimp.com> wrote:

> Greetings,
>
> I've had a long-term background project of cleaning up cdefs.h. So= far it's
> all been things that are definitely unused. My next target are some > specialized macros used to share code between K&R and ANSI-C compi= lers. K&R
> support in general will remain unchanged by this (any code using these=
> macros that wants to continue will need to arrange for that in their b= uild
> system). It may surprise many to learn with about 30 flags on the comm= and
> line, one can compile unmodified code from the 80s that conforms to th= e V7
> K&R language spec (for some not terrible definition of conforms to= a
> squishy spec).
>
> The support I'm talking about is __P, __CONCAT, __STRING, defining= __const,
> __inline, __signed and __volatile to nothing (only on some compilers) = and
> sometimes defining const, inlined, signed and volatile to nothing when=
> building when __STDC__ is not defined. This support was a transition f= rom a
> time, predating the FreeBSD project for the most part, when numerous > programs were specially curated so they could build on K&R compile= rs as
> well as the then newly emergent ANSI-C compilers that were appearing. = The
> need to do this has long since past, so I'll be removing the pre-a= nsi-c
> build environment support for doing this specific thing.
>
> I'll retain __P, __const, __signed and __volatile in __STDC__ envi= ronments,
> but have firm plans to remove them completely in a future round. I'= ;ve
> already removed all __P usage from the tree (except sendmail). The oth= ers
> have a smattering of long-dead-hand-of-the-past usage in the tree (in = libm,
> for example). I plan on leaving __inline unchanged because it has a > secondary meaning. I suspect the only wide-spread one that will cause = me
> grief is __P. All the others I see occasionally, but it's not perv= asive
> like __P once was (and still is in older projects, shocking at that ma= y be).
>
> I have no plans on eliminating __CONCAT or __STRING. Their use is
> widespread in the tree is extensive, and where they are used, it's= fine.
> There's no need to gratuitously churn things here. To the extent t= hat pure
> K&R compilers are including our system headers, this will represen= t one
> more tiny step away from supporting that (as they are used in our head= ers).
> But such environments need their own headers anyway: all our headers u= se
> ANSI-C prototypes w/o __P protection.
>
> As with all my cdefs cleanups, I'll do exp runs before I commit. F= or the
> more consequential ones, I plan on posting reviews. For the other myri= ad of
> completely unused and designed to tell gcc3 from gcc4 or gcc2 from gcc= 3,
> I'm just going to eliminate those.There's no point in keeping = them once I
> make sure nothing in ports uses them.
>
> I suspect nobody will care, except to cheer on the removal of
> no-longer-needed junk that makes cdefs.h hard to read. My timeline for= this
> and other cleanup of cdefs.h is 'before 15 branches'.
>
> Comments? Suggestions?
>
> Warner

Would we need an exp-run to find ports that might need some attention?
<= /blockquote>

Need?= No. There's nothing that will break.

=
Will I do it anyway? Yes. "Can't fail" chan= ges to this file has burnt me in the past...
<= br>

And the changes if p= eople want to look.

Warner
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Warner


--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 ht= tps://FreeBSD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2= =A0 Web:=C2=A0 https://nwtime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0
--00000000000007e54f060a9eeacb--