From nobody Mon Nov 20 04:15:07 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 4SYZ0v64r9z51rJh for ; Mon, 20 Nov 2023 04:15:11 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYZ0v24Lqz4Wdw for ; Mon, 20 Nov 2023 04:15:11 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.17.1/8.17.1) with ESMTPS id 3AK4F88Y098247 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Nov 2023 05:15:08 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.17.1/8.17.1/Submit) id 3AK4F7Ws098246; Mon, 20 Nov 2023 05:15:07 +0100 (CET) (envelope-from fuz) Date: Mon, 20 Nov 2023 05:15:07 +0100 From: Robert Clausecker To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: Some K&R support to be removed from sys/cdefs.h Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Queue-Id: 4SYZ0v24Lqz4Wdw 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. 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