From nobody Mon Nov 20 16:14:27 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 4SYsz53Vk7z51VPY for ; Mon, 20 Nov 2023 16:14:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 4SYsz51QMbz4Y92 for ; Mon, 20 Nov 2023 16:14:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-53e2308198eso6529563a12.1 for ; Mon, 20 Nov 2023 08:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700496879; x=1701101679; 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=FwZCA7F/cONTASAbqKqJvOEmKOXORnnKovF59JsgybQ=; b=KySe/GUVFtvOpK/55H1+4om0Z5cawnAwPy/MvHXaMfyh0xxXZYWvJ9U/d7L0e/9KYC iugDdsah6oZaYjtuCAA5ntBquCtofuBCgTdMRdYXCccqU6GE2TZonY5bM6BeHJz6rL2W TWnC6ioandDX3Lwl2drq5KiPmp7Or1Wucf/ikLxjqLeghXTjPAws2T8vvYmeZJhHhB5r gB1/+XQNAsip6LcsYu3TJliyom8VH2FfEWEFitDCkItz22Uzj4uUv7O673FSIHmblbaZ MXFTkPZuBWhBDyMxyPQgLAsBsbCcZkBs0uMhDlmoLbfclH/M/vc+H2FbPQbWlrj0XsiY 6BYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700496879; x=1701101679; 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=FwZCA7F/cONTASAbqKqJvOEmKOXORnnKovF59JsgybQ=; b=SA241BH+lGH8i60DKsbHFdC2IEh/VylO/G2FgjxoH1GAKVjaQFgdH7tARWH2/oJLnm jgsGt1kks+svZmfRIg6/PtrZxbE9WjaXCY/WQXp0ErndubCvxIZcYknB9/rOczp1X0XO cxO2ruZT4tvVN8K+auzRmu1WFMMMf/kPwxwQ8dk34HoSlt72aP+7ruYo7LM9NlY1lwmg ibukiKsZ0t1L4GqgkyKPPuji5BUZGPG2mEzylgOhlQ0yPkcliQq9U1SY08Eva/8luc6y hUnZr2OpVnngv/XMWk9HunPz3b8tKxowA41yQqsdjKW9m0xAW1uuOzxpgH3GK1U7ywk/ DiHA== X-Gm-Message-State: AOJu0YxEEfVRBfK6nNFCj5JIVAltsHdqPj3Je9uyo3phVAqOi6Z3zHwI keLEV0rP5pq4fJtHDOchpQ8b4+rLnfIlgL6jfXOckd/0hcw1WBF4 X-Google-Smtp-Source: AGHT+IFT+o0MvnHCSl9OLLUtH9HkweC4JU3+gzFB4hlIFdBUDK6jfiEosMbha0ARTwx0ItcdzagI6eo2xfjl52HpnhY= X-Received: by 2002:a50:e61a:0:b0:548:4c4e:11b4 with SMTP id y26-20020a50e61a000000b005484c4e11b4mr6305858edm.16.1700496879380; Mon, 20 Nov 2023 08:14:39 -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: <20231120080109.34bb47d6@slippy> From: Warner Losh Date: Mon, 20 Nov 2023 09:14:27 -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="0000000000006ffda9060a97c8be" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4SYsz51QMbz4Y92 --0000000000006ffda9060a97c8be Content-Type: text/plain; charset="UTF-8" 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 the > 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 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-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 pervasive > > like __P once was (and still is in older projects, shocking at that may > 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 that > pure > > K&R compilers are including our system headers, this will represent one > > 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 use > > ANSI-C prototypes w/o __P protection. > > > > As with all my cdefs cleanups, I'll do exp runs before I commit. For the > > 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 gcc3, > > 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? > 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... Warner -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > --0000000000006ffda9060a97c8be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 20, 2023, 9:01 AM Cy Schubert <Cy.Schubert@cschubert.com> wro= te:
On Sun, 19 Nov 2023 20:44:49 -0= 700
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...

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
--0000000000006ffda9060a97c8be--