From nobody Mon Nov 20 03:50:21 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 4SYYSM52m7z51pnB for ; Mon, 20 Nov 2023 03:50:27 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYYSM4Zzlz4SSW; Mon, 20 Nov 2023 03:50:27 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700452227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q3f3s1AmFmUXnOKWnTaODINNlLkqydX+wr/ewxWnr8o=; b=qIV+TGrZixauOFNZYbE4kLMgD3vPgb5cx+PrSF5Hhqf9rYBDE+V/2YcwBLRMd+18RS9ZM9 SfkV0sxNlj0j0gcmF0Vk0BVJ2sivBGmH7OhMk6epxHOBEB3NzeZpkUBzahwv5bRU/vo+5j 7/In0V0ItQZLbS/4UwiwF65ffP1/Bt7IjkmNk8ffMfYqDQU0WYERIIj9+X5xqM2Npv2TaL sO0+VHnsmdnF48i5XW3/dZBGOKCcj56/y7HgDF1/at7BauxqwE+FlIDAeHwdVCxOrdFdX/ Rjr13oWhPSHGnIj+CdcHl7qxf4ZmMFGb/ZtbrSiPmHGq7freSxkKAWi15hcLwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700452227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q3f3s1AmFmUXnOKWnTaODINNlLkqydX+wr/ewxWnr8o=; b=UWIaBLRSdD45wKHc0TSRrEkydmLhMedWG6eWY19eMQWmwdsYEtWDrdEPjPT5EGS1SGJfCl WLvMk4Kl4Vo7tcr+37gfbh7+/2HTWB1h0krB1RWI1ZlYLmmWlL1lF+eoe5usqf5RSGvXDF GfCvQIBKDaB3Y9v3B48ncUyRop+cuFNq1Bn5V2fcUfXykf0VpXkBH8/3FucUTn6aq9lk77 Xf8YVc7SprouG1YmNo1CH/v0moupNXT/SDXpkbgjFMA/F3O8I+Rn2wqiZetkVXmk7XoWGo UQfrsC8nbvGsNZQUkc3nU1XyjfWXJw9apxxNOnUwgCeKqei4dCKVa4Aivx4ESQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700452227; a=rsa-sha256; cv=none; b=YzxVfXy1OWfxMhz2HhzA9fKHeuUOGHKTFS0QjoxMyRbvpfwjc6EdMhfe/sMsStIcVlvsUa cZrpFuBeOHiJpcK4FSVWRFJROUsBSORCGIgJXXfVjHoybPTLog7ICfQMb0cGZlDtF+of9S AROBTBWuKZpcUl5mIf52aXXAvZbVh58OFrINlPgSyEOGGmEjlGr3gxjhcltVcaFXroUO3n EHy8ZKIpaX4DflqP9g51pifGKFzylLH1hN6PMstq+2+ywSO6frf6cyl5l5Msvg1lGca0Tf IWdNG2oCQFBARqqYlM3r2/co4pHTgol/e9lhgr0NcOiQG5nmiYfDnzEsFPi2ww== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SYYSL4jKYz9g1; Mon, 20 Nov 2023 03:50:26 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: Some K&R support to be removed from sys/cdefs.h From: Zhenlei Huang In-Reply-To: Date: Mon, 20 Nov 2023 11:50:21 +0800 Cc: "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.4) > On Nov 20, 2023, at 11:44 AM, Warner Losh wrote: >=20 > Greetings, >=20 > 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). >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > 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'. >=20 Yeh, cheers ! Let's move ahead. > Comments? Suggestions? >=20 > Warner Best regards, Zhenlei