From nobody Mon Nov 20 03:44:49 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 4SYYKt6gX8z51pcw for ; Mon, 20 Nov 2023 03:44:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 4SYYKs5FK5z4Qyf for ; Mon, 20 Nov 2023 03:44:49 +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=FCCWZmHd; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::636) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-9e62f903e88so510037366b.2 for ; Sun, 19 Nov 2023 19:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700451888; x=1701056688; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=OgWR7wQmB07BJTqK3OsamhT7y7EF9wNOa3gzQLt+gCA=; b=FCCWZmHdnrST98L7g4ITsbchRFDPiMVtwDGVjgyqnG7djB/0USlS2Z6l/Jv/RWffE9 OYB5SxvMk+o+mXTxsYzmE1oKo+Ax0fY5GdkaBUPnFYDNfCExF1XlrFkM5lYV/cVdEAhd DGy0A/SjADX7kd6Tlkk59vEWwJ15WcfNG2KtT5mHaa1t3ofIVdgfbyb2NDusY2kWutI/ PLqSfFaK3f47toY/HS6sQ3eCqIk0NAVFO4kyyhq/RJ+sM5Wa/+P0YglH1mpt16bkQiMM rmB4OA1yUufNmI5BfvhO1/dV8VVX7tPJyEdtbHefgTBcMC0cLCyBdEFP1oFrg/FdcGkA bkFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700451888; x=1701056688; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OgWR7wQmB07BJTqK3OsamhT7y7EF9wNOa3gzQLt+gCA=; b=a33a1gL5ptRtVNVOg9Siuxq1j5kATZkE2ja/HoThtwMq1sa8e96w7h0FjXnOUuEz+7 Nfjykb3VW5xR8CjeSZ00muXfVE3NBYD2froA93G+WvBC3iV9NKqoAISVHH5dcikPvOJs kbHg9icdL5kY6ml+F1bfK8R+3RwwSvnTgGfsjqxrvmo+IMc1Nhjqzj5DewrJnZCDI5gZ NEZQCqu44A/OT02/s369DNw+H1slx41OfRyXKnAFmDf67XaLbl7Chy+QHSnmeqRZvIbp fyYtjKKRCTVz6nQnDiKw4PDi9GanlYybMlalg55JTUV82GPsWaxiI1rk2kAMSyLbsdYC FwIA== X-Gm-Message-State: AOJu0YxgnCRGnqnvWC3yZ46PS86NPafT2+kQpDnUL6F18S7j9pEnmH2G IZ83szDyjQizq7p2KLEVIsQqx6svfpow6ewtgkRCeAz+aZ6htS7e X-Google-Smtp-Source: AGHT+IHeX/InX10k9LU/IyXZAbJ4Icxv00DlFXVPnxkJlWMKx11RpOyGQyardWOEIpms5iUjNZi5Xlwql5XMYD79Qwc= X-Received: by 2002:a17:906:57:b0:9e4:651f:60d0 with SMTP id 23-20020a170906005700b009e4651f60d0mr4944874ejg.9.1700451887362; Sun, 19 Nov 2023 19:44:47 -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 From: Warner Losh Date: Sun, 19 Nov 2023 20:44:49 -0700 Message-ID: Subject: Some K&R support to be removed from sys/cdefs.h To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000b44562060a8d4e72" 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]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4SYYKs5FK5z4Qyf X-Spamd-Bar: -- --000000000000b44562060a8d4e72 Content-Type: text/plain; charset="UTF-8" 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 --000000000000b44562060a8d4e72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I've had a lo= ng-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 mac= ros used to share code between K&R and ANSI-C compilers. K&R suppor= t in general will remain unchanged by this (any code using these macros tha= t wants to continue will need to arrange for that in their build system). I= t may surprise many to learn with about 30 flags on the command line, one c= an compile unmodified code from the 80s that conforms to the V7 K&R lan= guage 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 no= thing (only on some compilers) and sometimes defining const, inlined, signe= d 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 bui= ld 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 specifi= c thing.

I'll retain __P, __const, __signed an= d __volatile in __STDC__ environments, but have firm plans to remove them c= ompletely in a future round. I've already removed all __P usage from th= e 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 __inl= ine unchanged because it has a secondary meaning. I suspect the only wide-s= pread one that will cause me grief is __P. All the others I see occasionall= y, but it's not pervasive like __P once was (and still is in older proj= ects, shocking at that may be).

I have no plan= s 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 t= o gratuitously churn things here. To the extent that pure K&R compilers= are including our system headers, this will represent one more tiny step a= way from supporting that (as they are used in our headers). But such enviro= nments need their own headers anyway: all our headers use ANSI-C prototypes= w/o __P protection.

As with all my cdefs clea= nups, 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 el= iminate those.There's no point in keeping them once I make sure nothing= in ports uses them.

I suspect nobody will care, e= xcept to cheer on the removal of no-longer-needed junk that makes cdefs.h h= ard to read. My timeline for this and other cleanup of cdefs.h is 'befo= re 15 branches'.

Comments? Suggestions?

Warner
--000000000000b44562060a8d4e72--