From nobody Mon Nov 20 04:25:05 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 4SYZDb5Bt6z51sJm for ; Mon, 20 Nov 2023 04:25:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4SYZDb1HNSz4Ykl for ; Mon, 20 Nov 2023 04:25:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-548d4fc9579so195369a12.1 for ; Sun, 19 Nov 2023 20:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700454317; x=1701059117; 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=avBFDwqJw54ezXfngkfu8ata6JbFSKrYFSYbeMehAnM=; b=AEsaIh280C2q84ZUngrO8KN7rnSGUpA8/VhiMc70LAPTTv7FpyYaXEz4YDdQe6BTsD cBF6/HtoryR/8VPmgGneqneKfXz371983VrSAH5R4pPVVsA0JUWBbNEbbKyoqwfBcPGb GkjuI+eNOoWp1h9X845vC4iXG7XwcRUZkpYXOOU3mxUxAr7DmeGWdUuYenwreiTzXYEz kS7UVdYOBkZcYN1lWJ2tSxQXEPtLxeX2Tb37KrvHDDm9TYvOh4iNgpp0SAoaohpVJzrA vRd32S1mgTuThrYcfGlbQI1UyDC7kdXHrT+RmidVGK4KF8faz+6mEpda4Xp38GHL6mC1 qpQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700454317; x=1701059117; 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=avBFDwqJw54ezXfngkfu8ata6JbFSKrYFSYbeMehAnM=; b=xH+rY5bgv0e106oaehyg4mqNZ2+mXwKTN7M3xlkzGKGBMv3J3bUpKq5l9q4seIMWVb yTS81HXEGuHYbpK1zBeFqaU0V+eXFVWEjswCk98Mz/GkVGZFILPh9JKHii6Eus8Om8Sh JaT4ubYR0J8DIbLxs3VkQIgmRuemAgoYxvvGulUayoH29LU5ENil0HWAF/Vj6V1n6l8V q1HcqpsqcHohtRlGrbzCOJHXU4Op6SSXBIUfS46HZlCmusQ7CnE6++lbzH37sE0S3w54 v+EYnZkFDGPREPyrwTaA1ygyQRVcoK5srVPHsf23nO2Y6hxLSRlznMwr1bmjhl9kS2ko RjYw== X-Gm-Message-State: AOJu0Yz6NWeGQdvtHf20LlAzJNgmlwKj9H17f/ZIDtl2UMMXCZHZnsxp w0hQCL4rfO4BSkJj70qM2x8WTfyobbNFrQQW6pyqU+beDuPCzSLX X-Google-Smtp-Source: AGHT+IGTqOlOEDq9trpOMKBDET0DvPrDfsij4yqunvHONC0vKujj22y08i49bLzqZQLZ6oQvSPTic7eBXvx6mLVz1sg= X-Received: by 2002:a05:6402:1658:b0:548:ab1a:dc2c with SMTP id s24-20020a056402165800b00548ab1adc2cmr804353edx.9.1700454317455; Sun, 19 Nov 2023 20:25:17 -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: In-Reply-To: From: Warner Losh Date: Sun, 19 Nov 2023 21:25:05 -0700 Message-ID: Subject: Re: Some K&R support to be removed from sys/cdefs.h To: Robert Clausecker Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000008cb4a5060a8ddfb3" 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: 4SYZDb1HNSz4Ykl --0000000000008cb4a5060a8ddfb3 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 19, 2023, 9:15 PM Robert Clausecker wrote: > Hi Warner, > > __STRING and __CONCAT are still needed with ANSI C to change evaluation > order. > For example, I recently used __CONCAT in lib/libc/amd64/amd64_archlevel.h > to > build function names from pieces. ## cannot be used as that doesn't work > if > the argument passed to the macro is in turn a macro. Similar things apply > to > __STRING. > The only way to eliminate them is to rewrite them as same macros with different names. That's why I said they were fine and I'd not touch them except to remove the entire !__STDC__ clause with at this point should have no effect. Warner Yours, > Robert Clausecker > > Am Sun, Nov 19, 2023 at 08:44:49PM -0700 schrieb Warner Losh: > > 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 > > -- > () ascii ribbon campaign - for an 8-bit clean world > /\ - against html email - against proprietary attachments > --0000000000008cb4a5060a8ddfb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Nov 19, 2023, 9:15 PM Robert Clausecker <fuz@freebsd.org> wrote:
Hi Warner,

__STRING and __CONCAT are still needed with ANSI C to change evaluation ord= er.
For example, I recently used __CONCAT in lib/libc/amd64/amd64_archlevel.h t= o
build function names from pieces.=C2=A0 ## cannot be used as that doesn'= ;t work if
the argument passed to the macro is in turn a macro.=C2=A0 Similar things a= pply to
__STRING.

The only way to eliminate them is to rewrite them as same macros = with different names. That's why I said they were fine and I'd not = touch them except to remove the entire !__STDC__ clause with at this point = should have no effect.=C2=A0

Warner

Yours,
Robert Clausecker

Am Sun, Nov 19, 2023 at 08:44:49PM -0700 schrieb Warner Losh:
> 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

--
()=C2=A0 ascii ribbon campaign - for an 8-bit clean world
/\=C2=A0 - against html email=C2=A0 - against proprietary attachments
--0000000000008cb4a5060a8ddfb3--