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-- 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 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 From nobody Mon Nov 20 04:19:11 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 4SYZ5n0LMGz51rbp for ; Mon, 20 Nov 2023 04:19:25 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 4SYZ5m5cSZz4X1V for ; Mon, 20 Nov 2023 04:19:24 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-32dc9ff4a8fso2463898f8f.1 for ; Sun, 19 Nov 2023 20:19:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700453963; x=1701058763; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YHKfILuHmxyMDOKXrriJ3rOVGhO6Y/CWQI9WHLzq8W4=; b=ZNfVhUtOxTZFoeR1SyWyAIUtRxhwjA+M4tCsYKRNHwQtVoxfxpmhjLMSjlKEDG519f 7U6mmZ0ZTFFgnBNw7+J7MKuSuxLX1sGJs/HfXhqSHxL8pbOuIqQzTNOTyHSZHL0uJHDd raOkxbHSZZiyD7px4zCgYlD0xAKSeJ+p3ExXEIMJiM040Z4gSvLLcp9DYceIv6ICMIiV YnQecCrmnL1eJ2am+oDe59xiBkaiNQHSozm1EPf5ZrDbTGAQM9Lp0W2yZTpHKdSxdsNI IDLcJbwNORoinPTMwDn4aYusMhxJrnG/CR7p2pV4fDSihbIPRskjvxW9Qv4HuBvMDYem ISEQ== X-Gm-Message-State: AOJu0YybsRnmyG3XKfVx3em4USbsb0ajMVEzWpcHjMVEipihyyD3njUh nP+KVw3lm7+o5hgz6mpJeBtiwQ== X-Google-Smtp-Source: AGHT+IGkMZq78QxVR9teGNifGvc/2sP0DEPLgtMUE6qtN5zMfuffBgF8YLUr6VHKRkY1fu0fXUBzMw== X-Received: by 2002:a5d:5f90:0:b0:32d:9718:b32a with SMTP id dr16-20020a5d5f90000000b0032d9718b32amr4248271wrb.0.1700453962726; Sun, 19 Nov 2023 20:19:22 -0800 (PST) Received: from smtpclient.apple ([131.111.5.246]) by smtp.gmail.com with ESMTPSA id b15-20020a056000054f00b0031980294e9fsm9700932wrf.116.2023.11.19.20.19.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2023 20:19:21 -0800 (PST) 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 $3774.200.91.1.1$) Subject: Re: Some K&R support to be removed from sys/cdefs.h From: Jessica Clarke In-Reply-To: Date: Mon, 20 Nov 2023 04:19:11 +0000 Cc: Warner Losh , freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <50B3506F-B0BF-4695-A0B5-CFDB918D6DAB@freebsd.org> References: To: Robert Clausecker X-Mailer: Apple Mail (2.3774.200.91.1.1) 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4SYZ5m5cSZz4X1V On 20 Nov 2023, at 04:15, Robert Clausecker wrote: >=20 > Hi Warner, >=20 > __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. You mean __XSTRING; __CONCAT is to __XSTRING what __CONCAT1 is to = __STRING, confusingly (though __CONCAT1 is unused except for implementing = __CONCAT). Jess > Yours, > Robert Clausecker >=20 > Am Sun, Nov 19, 2023 at 08:44:49PM -0700 schrieb Warner Losh: >> 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 >> Comments? Suggestions? >>=20 >> Warner >=20 > --=20 > () ascii ribbon campaign - for an 8-bit clean world=20 > /\ - against html email - against proprietary attachments >=20 From nobody Mon Nov 20 04:24:15 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 4SYZCQ49phz51s4V for ; Mon, 20 Nov 2023 04:24:18 +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 4SYZCQ2sQxz4Y7F; Mon, 20 Nov 2023 04:24:18 +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 3AK4OGK0098314 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Nov 2023 05:24:16 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.17.1/8.17.1/Submit) id 3AK4OF6c098313; Mon, 20 Nov 2023 05:24:15 +0100 (CET) (envelope-from fuz) Date: Mon, 20 Nov 2023 05:24:15 +0100 From: Robert Clausecker To: Jessica Clarke Cc: Robert Clausecker , Warner Losh , freebsd-arch@freebsd.org Subject: Re: Some K&R support to be removed from sys/cdefs.h Message-ID: References: <50B3506F-B0BF-4695-A0B5-CFDB918D6DAB@freebsd.org> 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: <50B3506F-B0BF-4695-A0B5-CFDB918D6DAB@freebsd.org> 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: 4SYZCQ2sQxz4Y7F Hi Jessica, Am Mon, Nov 20, 2023 at 04:19:11AM +0000 schrieb Jessica Clarke: > On 20 Nov 2023, at 04:15, 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. > > You mean __XSTRING; __CONCAT is to __XSTRING what __CONCAT1 is to __STRING, > confusingly (though __CONCAT1 is unused except for implementing __CONCAT). It could be that __XSTRING is the one for stringification. I didn't have a need for it so far if I remember correctly. Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments 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-- From nobody Mon Nov 20 16:01:09 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 4SYsgY3KcFz51TZ5 for ; Mon, 20 Nov 2023 16:01:13 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYsgY1QQSz4VQw for ; Mon, 20 Nov 2023 16:01:13 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id 4jLLrAECMB0n056hzrtx5V; Mon, 20 Nov 2023 16:01:11 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id 56hyrvNApU5YW56hzr6JiE; Mon, 20 Nov 2023 16:01:11 +0000 X-Authority-Analysis: v=2.4 cv=CZQbWZnl c=1 sm=1 tr=0 ts=655b82c7 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=BNY50KLci1gA:10 a=7Qk2ozbKAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=MveOevlX2-Qt8mWo66QA:9 a=CjuIK1q_8ugA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 41EA15EC; Mon, 20 Nov 2023 08:01:10 -0800 (PST) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id CEBBB1E3; Mon, 20 Nov 2023 08:01:09 -0800 (PST) Date: Mon, 20 Nov 2023 08:01:09 -0800 From: Cy Schubert To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Some K&R support to be removed from sys/cdefs.h Message-ID: <20231120080109.34bb47d6@slippy> In-Reply-To: References: Organization: KOMQUATS X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfFMOeK6UtWXGJ/kW1hBWYRFsvtyZJRKCWDCOJ0ZGJfGk9H2olRuFAWEMYJIvnAm1EdZ+QM1N6eOZvely/o+t0Mc96oAo64VFiUSv/sBIPyCUhHJgm2ze HEjRIGAia0oBwFvOw6hj6wMkY4YmcN0B3iN1aCHqut4OObmqTjRlOwymG1vC7SrvIS6JxpQdew5xrrSuP10/qlm5pxAMfdm2mhmrkFNiIooSAodxKzl4IHS9 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:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4SYsgY1QQSz4VQw 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? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 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-- From nobody Tue Nov 21 00:44:56 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 4SZ5J71QwHz51P2R for ; Tue, 21 Nov 2023 00:45:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4SZ5J55SWYz4YJY for ; Tue, 21 Nov 2023 00:45:09 +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=N9KUijME; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52f) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5446c9f3a77so7286910a12.0 for ; Mon, 20 Nov 2023 16:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700527508; x=1701132308; 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=JDc6mZ3wFxmMsDzCkZw9fiUL//nxfAAtWPUeLaAaHfI=; b=N9KUijME3whvtuMc+ZgmYLVTPe8i+a7uCVuaxwY+VF29TXexlQoazZckO3Jiw6bTOO etbBSM6lqrHdu/JBlvtJ6vgt6nqJ4yIU8PHTlRmun9O1/d9MLjMchSXmAbdhgROzvRFC pR2xXk1pcRi0JlpBqIfp4APOGBu3j6QZKxHrIi3M4rIVY753GCdiZVO1jPNrnn9txVku qZBYlp0ZYgnUHPwHaL9IggEnuhorYCPetgcoNoz+pO0OC2tJfNqMwf64oub81kYIxHZK uWLMCjDraQeqS6es7bltc9M70MI3f9CnTI1Lrar9yOeiwbWvWDgXQmqmSKximBCunqeT Cl4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700527508; x=1701132308; 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=JDc6mZ3wFxmMsDzCkZw9fiUL//nxfAAtWPUeLaAaHfI=; b=DOrGVL2eq1KrSQpyTKgOjnhpbxNHZ7DTd2lRpc6Wr50jC1HJs/qSTzw2Y5YDmXItyP fSfPiDWgpRPBV6jpz64NYcfnpIlf4IEPcxmXLte+hzhhGIHCyJZ7U0g6TLCigDgdSkeG Y5Wa+aWhzOmqUIiLWm9nPdw8C4QZqc63AJSkvKt3fP///Ght5uz/xtudII1WBwJW37Ay /VJhonGA2NYqGIEROdVa0IbgVVfHSbzALHyBzj/aINQr9IAGdExeISYr2eYd9fFCrUhX oGQg2Tz9utNcTzoDQWCLmu56CGMlgGyW/u6msrjUH3laoe8/w/tRMPyQvN0wfG/nK4lM 5lVA== X-Gm-Message-State: AOJu0YwYTyz1Bwp9YnQGFQEj5DJ2cdb15QK8xO6j00bqep7+t4C07WcA Cg0EhQ+bsOb7z/Ghg6gAXHwz+TMQLCsrFHOjLkACou6Ug3TPdadxdCE= X-Google-Smtp-Source: AGHT+IFW4UKGH3kCQ1CwgJIBXmv93TQp1aKcSN/07KDmGbLwE4nJBMw9E5kmFydsoadlf7HcvYvayo0nRTW2xF8eRew= X-Received: by 2002:a50:9518:0:b0:540:4b90:3dc3 with SMTP id u24-20020a509518000000b005404b903dc3mr693219eda.14.1700527507755; Mon, 20 Nov 2023 16:45:07 -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: From: Warner Losh Date: Mon, 20 Nov 2023 17:44:56 -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="00000000000007e54f060a9eeacb" 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]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4SZ5J55SWYz4YJY X-Spamd-Bar: -- --00000000000007e54f060a9eeacb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 20, 2023 at 9:14=E2=80=AFAM Warner Losh wrote: > > > 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 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 >> 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 a= s >> > 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 pervasiv= e >> > 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 fin= e. >> > 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 on= e >> > 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 u= se >> > ANSI-C prototypes w/o __P protection. >> > >> > As with all my cdefs cleanups, I'll do exp runs before I commit. For t= he >> > 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 gcc= 3, >> > I'm just going to eliminate those.There's no point in keeping them onc= e >> 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... > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275221 has the exp run queued up. And the changes if people want to look. Warner > Warner > > > -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: https://FreeBSD.org >> NTP: Web: https://nwtime.org >> >> e^(i*pi)+1=3D0 >> > --00000000000007e54f060a9eeacb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Nov 20, 2023 at 9:14=E2=80=AF= AM Warner Losh <imp@bsdimp.com>= wrote:

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

<= br>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275221 h= as the exp run queued up.

And the changes if p= eople want to look.

Warner

=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

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

--00000000000007e54f060a9eeacb-- From nobody Tue Nov 21 16:12:48 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 4SZTtk2zY8z51sbj for ; Tue, 21 Nov 2023 16:13:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 4SZTtj5CHMz4VJX for ; Tue, 21 Nov 2023 16:13:01 +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=dkqWq5mg; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::12f) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-50aab20e828so3640979e87.2 for ; Tue, 21 Nov 2023 08:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700583179; x=1701187979; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=noVUIXSFbrArBeP8t/T5lXBZVcumcRgme94xU0mRH8M=; b=dkqWq5mgXUNYIrTuMTdj4/nBfbmGa8ervDum2AhuxjtGWNd1ife5VID/yxzm+BseSe Sh4nll1hAXDOLUIXCJh5PVVFbf7UAN3TML43QqvehqvOkSpj4nlTUWHa0XlIcJiHx96d cNTM9iWKx798Pmql/4RAvXSq9RbWm72jKYensJGjImWs/wo2zRvvJ5R6gdEySBjew0Ne c4FMIGlq6CcWO8SHqHJxyqMS0DiTTqzmAKLCbAjpaY1JvZ6pvQVMRbdnZRUwQpUtlpfl 4p8+tSgv8tfHU9sWa9MfKMAWihSoE7BGQwYbQ+5qOxBCSRjcImFb3g4PvJt5W9TcgW6K DV+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700583179; x=1701187979; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=noVUIXSFbrArBeP8t/T5lXBZVcumcRgme94xU0mRH8M=; b=am8HWTQf6YbuazUL2zsrMZeN4DS5VXDgZb4JqyX7ICBTQYQsfOSQm8NMou1gPEnkWs uNWcFQyIPjkeE7yui/rHhF7PFbY2Dhi4+DQtEp9AIJG54qfC6gRzPtvpJWoUmZTjFuab uR8VRraSUguuQxxxHoUL0avO+n+OTEzq3nrUvfsyoJdbTnr0PfCS2lIZ6SRWHzrxtMtL kJBG/dJEfyVYRl0b3L6X3c5PQ/vpJtnZ6LuPr4XjcUZeGIACR3WLkDohss1yob1GPFEQ wg7VAFHCtrWAWHNKqjQJGBepLxNmwt5/B0KN3UhtIUiCUMMiEnZX8jGLGfdGPRK2Z2EY Ej9g== X-Gm-Message-State: AOJu0YwOv2tiQAR3aD7k4fWMx/FIobgq0iwgbN3M8RJrIRn8v3cEUcOU p4ztU9x1DR7qr+TX+wJR0v6mmZMy18DnSIfkTkRZb0Q58XVrsORb X-Google-Smtp-Source: AGHT+IE71nZ/cBBArALzo9bnTKmGTt1EvMSrzU4He3TMP58wji3WOBN5614vavke+ixjqYDJ6iadMAHrxtwdSqLs1uU= X-Received: by 2002:ac2:4552:0:b0:509:8e1b:c932 with SMTP id j18-20020ac24552000000b005098e1bc932mr7847097lfm.50.1700583179439; Tue, 21 Nov 2023 08:12:59 -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: Tue, 21 Nov 2023 09:12:48 -0700 Message-ID: Subject: Time to remove sccs tags To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000527439060aabe06d" 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)[-0.997]; 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::12f: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: 4SZTtj5CHMz4VJX X-Spamd-Bar: -- --000000000000527439060aabe06d Content-Type: text/plain; charset="UTF-8" It's been 30 odd years since the last csrg release. They are no more. At this point I think we can safely remove the few sccs tags that remain in the tree. The data will be there in git if we ever need it. Comments? Warner --000000000000527439060aabe06d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It's been 30 odd years since the last csrg release. T= hey are no more.

At this point= I think we can safely remove the few sccs tags that remain in the tree. Th= e data will be there in git if we ever need it.

Comments?

Warner

--000000000000527439060aabe06d-- From nobody Tue Nov 21 16:41:10 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 4SZVWG2hqHz51vb0 for ; Tue, 21 Nov 2023 16:41:14 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SZVWG0rykz4YDL for ; Tue, 21 Nov 2023 16:41:14 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3ALGfB9E077992; Tue, 21 Nov 2023 10:41:11 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1700584872; bh=cs3/FOpGtAWIpn/nWSyLKOYgAQMAkz3dg6UPAGzTErs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Tf5bjOwkLjpgGJBDmPLARtM+4qNYmXGuU8d+GZazpIKo3FIbbEx6pseVCwCSvRbbd Rhl7mLTaJdomERf+vxKSqQDaeuUaA2Oic+ys0y9grpXVjeN/WtV/y9iGT2J5RQDIPp j3btJ61I3oqxhR/1TFTrtEjuDyVYi9Vjs0xJNqEdI5NyM2sjFZFjnWO1hY9pHiFCit 9Nm5W7VobRrCOZlkNarnJjAcw8CAQOt8b57vM8ecEJynz8DEOxPIpWh0kqTpi4apOy 5iHRST6tC24diWUPt52if8TiBMT7SFSup47rt72zoJZGRCXcApWaZK90LKKvctXW9s 6jtvl3S7hu7Lg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id ysGdKqfdXGWmMAEAs/W3XQ (envelope-from ); Tue, 21 Nov 2023 10:41:11 -0600 From: Mike Karels To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: Time to remove sccs tags Date: Tue, 21 Nov 2023 10:41:10 -0600 X-Mailer: MailMate (1.14r5964) Message-ID: <3EAF37B4-2621-42BB-9477-F19A8E6666B4@karels.net> In-Reply-To: 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 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:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4SZVWG0rykz4YDL On 21 Nov 2023, at 10:12, Warner Losh wrote: > It's been 30 odd years since the last csrg release. They are no more. > > At this point I think we can safely remove the few sccs tags that remain in > the tree. The data will be there in git if we ever need it. > > Comments? > > Warner I think it is (past) time to do this. Probably little similarity remains, and the copyright is enough to know that a file is derived from Lite*. Mike From nobody Tue Nov 21 17:11:34 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 4SZWBQ618Yz51yHS for ; Tue, 21 Nov 2023 17:11:42 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SZWBP51XCz4dLd for ; Tue, 21 Nov 2023 17:11:41 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.de header.s=s31663417 header.b=E7sIF3MA; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.17.20 as permitted sender) smtp.mailfrom=garyj@gmx.de; dmarc=pass (policy=none) header.from=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1700586699; x=1701191499; i=garyj@gmx.de; bh=bXsTUI7xU6PLn+T4/qRVigXVYTna5VqWU+ffmj8NO1c=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References: Reply-To; b=E7sIF3MAknC01MYuxYpVSTjCdP30dYZeY/Ma8/j9AeN+smh5ZoZfBCUtKDYneDpp LyUJN6flEY8mbAduqdCnLB4ECEgIqo1ln9kf73O+eI1FB/klrFv+9Cro9vGzj2qYa Js4V0tsIVgvbbV+s5vCfEM0q2UJ4sshH405hgbv6wtbYldVA9dJMkZo8G7SSZoC7B PAR2rgCS64sfmJc7nd3vZak3eBZG8qzQ/dfy1WwZchtwPlge1OO7ae0480OAtKi9r szEeO9jgvriNpA4GRFXlsB9Aj1+f+hLV+MoRtmECVoZBuOdwONlbMJ969QaIrng5Y 5VsMZ2NREMVHReplkg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([217.226.57.134]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MRmfi-1quwgj34lG-00TCUk for ; Tue, 21 Nov 2023 18:11:39 +0100 Date: Tue, 21 Nov 2023 17:11:34 +0000 From: Gary Jennejohn To: "freebsd-arch@freebsd.org" Subject: Re: Time to remove sccs tags Message-ID: <20231121181134.28c93c6f@ernst.home> In-Reply-To: References: Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:9vNga4WHs/TsuRbF+v9t0hT/nC+5c1SN+5AgqB3/ET9a7dwZ/Xc TqkSrsJRK21Tz8CgBBVqRvpmpQNIlWacjJLCCsEYwnge5kcOpUSh9bbZnde5a3SaZ0+UcmD q5TWa0TlZSGZefIJQcgiZjMZfPTygq3Fpo6zT1YZujPyuqawMK1crnaVJnQYhendWd88NTQ 4wISNPCx2UZseLJdlGXoQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:2Nf2PMtjKAc=;wLJ1oh5DJxYJBu4rAPeugE1uFW7 Y6zNTz5XdnJg5krYoJ/6+Uwsx+8PI1ONoTFC6KKGhJwkrcPx4MFmBxfyzd63JXt96/qCpmVxX w+VjtaUJ5lEsER10bNH9P/7cRAgcf78Gy7lLgtwCLHCWz/aZZdRCY8WoD8XblJfTEc5cMmrKU syQD2zG6aeo8RI88VCoojw79wg0dldqlV6NyYW3vpKvYziGgYDHZCTusKR2oibZ6R4v8cIqZL ZNr0t71x2TgjmvCMnDAhyjQCl07qm0xJxfNqgl3+FvYz85y0FaOmcW8DMbv7bdztf23HQIi3E 1wchVbwvvolbsTG4U4aSsAXHSCueLAZkR4TiWQlEr/RRjnkzuKKW0iJ1qDMsOFsrAt4OXbKeb R6qv8hC0bDn975SftrygYxEq/ODCdBfDpLF7WYhUG+VbeBwOYzZ72OrSRopuqnwEqRHE4EESB bhUbMFhi7QyS0gmlK1Sqsj6IQvx90TlN4vU9YaaMXQRpFp/Hc8Ccx4yw3ueSMPvicS0uuz8Wj nCbPKcuG0+3zhQ6MXv/MZC8V0Xtd/MJa3S3gJeYv3mpxQMGDuHzZZH9nVuXUo97VT9p3keBzY rvV8ZeqUpavS/uZ1HXnBhNpgjXkTSYTN3hdkNnHgVnnBBGHT5wmLsr4mYFOS+WSTVwC6yYxv8 fcSzIxE7/9QXJxCaTaBZcyJ/MvPJ+bXpP8R4CPx8mIkuYTIHw9V+jNPcfBg/Uy4MiQBPgPAiM JndJhVoWdWss2ffm8lk+b73j4gTEhBBvCKNlwH8cfJNLo0zuRFa5KiKCrxOZP6k87MwD2K7XO eIbIGbLs6q25PYUpsIWpskTZ83xaiJ68R4fuYHe7gye1bUaeM73zl1IxTXGB7bqMOzdlQtzb1 GU02SBqcuZ09z1vuST5VvAp/VUiS2WFlq36z8Tm84Qm/0hMihTcFejIaTRm665pU6ITjf1ivI d+TOQSaBGKrdq1nuM984vxR7smM= X-Spamd-Result: default: False [-4.17 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.965]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,none]; R_DKIM_ALLOW(-0.20)[gmx.de:s=s31663417]; RWL_MAILSPIKE_VERYGOOD(-0.20)[212.227.17.20:from]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmx.de]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; HAS_REPLYTO(0.00)[garyj@gmx.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmx.de:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmx.de]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SZWBP51XCz4dLd X-Spamd-Bar: ---- On Tue, 21 Nov 2023 09:12:48 -0700 Warner Losh wrote: > It's been 30 odd years since the last csrg release. They are no more. > > At this point I think we can safely remove the few sccs tags that remain= in > the tree. The data will be there in git if we ever need it. > > Comments? > Good idea. =2D- Gary Jennejohn From nobody Tue Nov 21 18:03:25 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 4SZXLD3yrdz522hP for ; Tue, 21 Nov 2023 18:03:32 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SZXLD00LRz4l94 for ; Tue, 21 Nov 2023 18:03:31 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id CEB323C019A; Tue, 21 Nov 2023 18:03:25 +0000 (UTC) Date: Tue, 21 Nov 2023 18:03:25 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Time to remove sccs tags 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:36236, ipnet:199.48.128.0/22, country:US] X-Rspamd-Queue-Id: 4SZXLD00LRz4l94 On Tue, Nov 21, 2023 at 09:12:48AM -0700, Warner Losh wrote: > It's been 30 odd years since the last csrg release. They are no more. > > At this point I think we can safely remove the few sccs tags that remain in > the tree. The data will be there in git if we ever need it. > > Comments? Yes please. The history is there in there repo(s) and there's so much blind copying where the context is entirely lost. >From my perspective it would be nice to have fewer commits per-subtree than with $FreeBSD removal. In recent spelunking I've found that for low traffic sub-trees I'm seeing a full screen (~50 lines for me) or more of those logs before getting to commits with content changes due to inconsistent formatting leading to multiple removal commits. -- Brooks From nobody Tue Nov 21 18:09:57 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 4SZXTt4YVBz523SP for ; Tue, 21 Nov 2023 18:10:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 4SZXTt45Xkz4lmD for ; Tue, 21 Nov 2023 18:10:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-9c773ac9b15so801911866b.2 for ; Tue, 21 Nov 2023 10:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700590209; x=1701195009; 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=JV0Q3ZsJmg2+2DNAPgdkxJQRo5vl2U9M7U9DoR7OIY8=; b=XjLWAa6QapNvrem8Zz1qugMyQ4baml0Ys9I+jlEaI6KqqWbbjgXrROwFHq89xs/ZMw k+3Yg+lsX28qmiBoUkTRoWd4i+dm39rnihIWFAbbGoO1drId+Zj66pMCAQIg3vXC73Qb 1swoUxPi78x45j7l7HUwBlBMarSBKXKR4PzeUu0GJ3BgcdIU+kLdD8MJvgZOJL7yE99E Grl29CAVlB0pMFikX+25P5X9BK25YVejtqT2JcEIHYbcPwi7C8CsU8Qd6c7z5swxVB3J L8YBjzK4Ep4nPSXpAd0LJXYw0gMZFL/B5IzAJ5Z9M9IG4ylgQBm1Z8wfbVseJRe8exoU kY8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700590209; x=1701195009; 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=JV0Q3ZsJmg2+2DNAPgdkxJQRo5vl2U9M7U9DoR7OIY8=; b=ZRG2N+QSpdZfPEu09xMhAOPrt9n3Zjbrc2tAuUgXjn6BhRFsqI0I3+3gY2Z3CA3QWy whI7//FcaqqcUwKeQqYEm/Ls2IG2cyFyAgs4O2JFMCBQ9QctzelPfl+Ihd5dq7yEsOvd KXK6IuNDatdpoW9mZxrocifEMS7YiJAd1YxoaioparYPF2JIHaNDl/Z07KH2nzSJUgC1 IQEZcLtvRhV6V2Er/l5SOKE17K9C5R/Q2DePvcNGHS0fP7NIMLq8v9dlyWZFqgAbi97W xw6w+pBcST34KO+cx7C6CJGM4R+HJQyhaOp9di5uX0PVhZdIsb3L9PxVx+2Q7/LI63J+ YFJg== X-Gm-Message-State: AOJu0Yxx9XyQ/ccoT4TF1EfO5ikxNjYnWv2TwUDsqB/r/b82cxGxnIwV DXhNpPmGjJsUYhrhXsnznu3lvf7+J69eew6OEJ1L96xsHNEKta6p X-Google-Smtp-Source: AGHT+IE/YW4nL01gHsq3yF8J0ZtTTWJHCQFQA58+tZVGk394EbN+J88qdpBw0xXhpmf7mNwQn9+yR6KWizBgGgbHYkE= X-Received: by 2002:a17:906:2290:b0:9a1:891b:6eed with SMTP id p16-20020a170906229000b009a1891b6eedmr6755499eja.76.1700590209011; Tue, 21 Nov 2023 10:10:09 -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: Tue, 21 Nov 2023 11:09:57 -0700 Message-ID: Subject: Re: Time to remove sccs tags To: Brooks Davis Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000005123d2060aad8371" 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: 4SZXTt45Xkz4lmD --0000000000005123d2060aad8371 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 21, 2023, 11:03 AM Brooks Davis wrote: > On Tue, Nov 21, 2023 at 09:12:48AM -0700, Warner Losh wrote: > > It's been 30 odd years since the last csrg release. They are no more. > > > > At this point I think we can safely remove the few sccs tags that remain > in > > the tree. The data will be there in git if we ever need it. > > > > Comments? > > Yes please. The history is there in there repo(s) and there's so much > blind copying where the context is entirely lost. > > From my perspective it would be nice to have fewer commits per-subtree > than with $FreeBSD removal. In recent spelunking I've found that for low > traffic sub-trees I'm seeing a full screen (~50 lines for me) or more of > those > logs before getting to commits with content changes due to inconsistent > formatting leading to multiple removal commits. > Fortunately there are way fewer files like this so I can do fewer commits that are still macabre. Warner > --0000000000005123d2060aad8371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Nov 21, 2023, 11:03 AM Brooks Davis <brooks@freebsd.org> wrote:

On Tue, Nov 21, 2023 at 09:12:48AM -0700, Wa= rner Losh wrote:
> It's been 30 odd years since the last csrg release. They are no mo= re.
>
> At this point I think we can safely remove the few sccs tags that rema= in in
> the tree. The data will be there in git if we ever need it.
>
> Comments?

Yes please.=C2=A0 The history is there in there repo(s) and there's so = much
blind copying where the context is entirely lost.

>From my perspective it would be nice to have fewer commits per-subtree
than with $FreeBSD removal.=C2=A0 In recent spelunking I've found that = for low
traffic sub-trees I'm seeing a full screen (~50 lines for me) or more o= f those
logs before getting to commits with content changes due to inconsistent
formatting leading to multiple removal commits.

Fortunately there are way fe= wer files like this so I can do fewer commits that are still macabre.

Warner

--0000000000005123d2060aad8371-- From nobody Wed Nov 22 05:15:14 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 4SZqFM39lsz51ptP for ; Wed, 22 Nov 2023 05:15:19 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4SZqFM2jYPz4K65; Wed, 22 Nov 2023 05:15:19 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700630119; 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: in-reply-to:in-reply-to:references:references; bh=PrqcnzQdkQc11IiA8efdOQmcbQgoVZfFbUPo7oGI55M=; b=f5b0dRNoYXuSiUdHJciTjAi8ZMBTuBi0aEzSBKYM8tkP3xsjrdYDRTb0dbRkp2v1YqocRv p1Vksez2ENxb/0HWtyX+libTaP7YpKLSPyf2I2doopL+6LSigf79HyFDX9JMr3WTe9Mkkp EeU+I39lhpzrVWZBEd3fJfVvtNJFDK70fNhzI7Nl34CddDIMj62Lzci/iJPn1srEllJmtJ MBZLgVUxN52CuMhS0Hm5M7hHubnrMbgnG/UEnQN06BLMwP1KlFllUBjUppgkJhhAWOqK8I wBj1n7igTbdPlCZflkNq9yndL/8T6yFTpW9GgyOhOcyiTzb2g/SEfyzxAh+Pbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700630119; 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: in-reply-to:in-reply-to:references:references; bh=PrqcnzQdkQc11IiA8efdOQmcbQgoVZfFbUPo7oGI55M=; b=cqY9P1Ailr/GUx/ZXcWZz/Q1glpl1IzbN/OeVLNnidnREx6xjYqAPahADBRmIwstDFsVvF b0M9wWdZmfgMdgf/2w2rEw7RwnMYxhirxv6uGpG9GF0/VQx169SGbgOihYJ+eaNQQQlnE3 qz3scrmJU0/1EdCLkXnHwfmAoZRFGtr5oA8VGQuuAEtz70DjJMtcUb8b4BBnV2JkiDtJf9 oygs55PiBf4XJ7n8SUJpxxAJuhLpNyO55PVCGfwQIGChz0A242elNL9X82PeYF22n4pElc uonnr9blDwAZTqZu83ilqDh7OeXQsEkxHdYa5JE9hbK75p99IQYqRbJyCEUjiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700630119; a=rsa-sha256; cv=none; b=iewsYTi9R7ZdZDZB58PY4MBTOk5BDffFgm9fTaeGNqqDclxluFCv/LAZg14V7/AFNEPnXz hx2eUy1lLdZK2tN6J49AL+Cbq15VSPmOn9OCqwiU0dWN8Z218bA6xbpf6zRRb3VCugIwsU Ao94bWMSKt+3JkeLqA/moiOafEzPct+L41dporc6Yotw3JeFQLe0cDN2OoSm2RUlWNMYMO aLr8gdYsDCs2uQh1n5rCmkoYkv+pVy8PXVbmTAPuxm9NL0YwZ/jNmr6JhUKa8M5qf7tScj 7lxN3i1goVrFi6AM24Crmd3KqNNf4V/w7ulyne9NYMlcs3FeFWUyHx6YKX5Djw== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (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 did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SZqFM1Z89z1b86; Wed, 22 Nov 2023 05:15:19 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id D6D3927C005B; Wed, 22 Nov 2023 00:15:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Nov 2023 00:15:17 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehtddgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevufffoffkjghfgggtsehttd hmtdertddtnecuhfhrohhmpefrhhhilhhiphcurfgrvghpshcuoehphhhilhhiphesfhhr vggvsghsugdrohhrgheqnecuggftrfgrthhtvghrnhepgffgfeeigeettdeltdfgvedtff dtgedvheeuieetheetfeeifeevveetvddvkeegnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpodhmvghsmhhtphgruhhthhhpvg hrshhonhgrlhhithihqdduudeiiedviedvgeekqddvfeehudektddtkedqphhhihhlihhp peepfhhrvggvsghsugdrohhrghesthhrohhusghlvgdrihhs X-ME-Proxy:

Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 22 Nov 2023 00:15:16 -0500 (EST) From: Philip Paeps To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: Time to remove sccs tags Date: Wed, 22 Nov 2023 13:15:14 +0800 X-Mailer: MailMate (1.14r5999) Message-ID: <22458D4C-35ED-4040-AAA1-A43006C0B32F@freebsd.org> In-Reply-To: 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; format=flowed On 2023-11-22 00:12:48 (+0800), Warner Losh wrote: > It's been 30 odd years since the last csrg release. They are no more. > > At this point I think we can safely remove the few sccs tags that > remain in > the tree. The data will be there in git if we ever need it. > > Comments? Long overdue. Since we're removing all these tags, should we also remove what(1) and possibly ident(1) from the tree? Removing what(1) should be non-controversial at this stage. I can imagine some people may still be using ident(1) on extant Subversion systems. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From nobody Wed Nov 22 05:21: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 4SZqNf2fbpz51qQG for ; Wed, 22 Nov 2023 05:21:38 +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 4SZqNf04NDz4Kn1; Wed, 22 Nov 2023 05:21:37 +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 3AM5LRUA007032 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 22 Nov 2023 06:21:28 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.17.1/8.17.1/Submit) id 3AM5LRKG007031; Wed, 22 Nov 2023 06:21:27 +0100 (CET) (envelope-from fuz) Date: Wed, 22 Nov 2023 06:21:27 +0100 From: Robert Clausecker To: Philip Paeps Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: Time to remove sccs tags Message-ID: References: <22458D4C-35ED-4040-AAA1-A43006C0B32F@freebsd.org> 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: <22458D4C-35ED-4040-AAA1-A43006C0B32F@freebsd.org> 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: 4SZqNf04NDz4Kn1 Hi Philip, what(1) is part of POSIX, though I guess you can just install devel/sccs if you need it. Yours, Robert Clausecker Am Wed, Nov 22, 2023 at 01:15:14PM +0800 schrieb Philip Paeps: > On 2023-11-22 00:12:48 (+0800), Warner Losh wrote: > > It's been 30 odd years since the last csrg release. They are no more. > > > > At this point I think we can safely remove the few sccs tags that remain > > in > > the tree. The data will be there in git if we ever need it. > > > > Comments? > > Long overdue. > > Since we're removing all these tags, should we also remove what(1) and > possibly ident(1) from the tree? > > Removing what(1) should be non-controversial at this stage. I can imagine > some people may still be using ident(1) on extant Subversion systems. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Wed Nov 22 05:41:43 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 4SZqqz5KzNz51sJv for ; Wed, 22 Nov 2023 05:41:51 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4SZqqz4vy3z4N4D; Wed, 22 Nov 2023 05:41:51 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700631711; 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: in-reply-to:in-reply-to:references:references; bh=sssx/PSRK9kWOta/YtC1AzAxVeGFvctNkRSuH4ZVCms=; b=AJ0ul6n7ReiGvNgFJzhlJP6zZRLYUQLRCFLrpcjf6GFGEXOaQCDcU+/h4r4xhVntaqQKm7 PSKSxeWVO+ErC1fprmmnY/shbCgZNISKGG5CNZHpqaL/vf6rII6FO+Koi9ADTiqp3NjmKm m/Iw/LEw2O/3GTds1mPao2woniAaWVW62dAzQV9YrBMnXsUICptmxB+wXaXOrxtCnnGMfG A0kC/cP9a5jTzdHx5pFaSikaKZOmgAuuMiYORFoqgZUwehQaTE7naUs0NDT3NxU2tgRqd6 Nl+8u+AmXDHmMKBtjxy+6+oid5cO3vv184BbraOKK1zwItPh7cnEg38xRTY3xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700631711; 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: in-reply-to:in-reply-to:references:references; bh=sssx/PSRK9kWOta/YtC1AzAxVeGFvctNkRSuH4ZVCms=; b=CEhPJjkhwzyUH/4rdbsdYGmh695v71b1NUUH0wIR6WhlGm5/hyU2lQgBtpNOfHKqSTQQXT 34uU3TzTprUEw5wq+azYRvb4pQQQhKAL7dPhQb7PAEFpKYLk8m8uVA20FHOq1WcKtEUGPX 4g8aA0RDjIgEgxFDf3t6OsAVKQLPsIicmYee42M+Z6OxkL+RJEYyMHnCv9lYo5yK8ZKEiL XlVWrgdJSzAqJPyS7whu1/1RT+o52g7a+9Dtp+i2pOK6UrjNHG2TzB7iOepcY+VOGqhLeE /BkMH2hJP1/HpLrWdLDxoaRqbp4ZmHVFPfkSRutiScMcsdtIR2PMqlpcUzk/DQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700631711; a=rsa-sha256; cv=none; b=LKByAa+GqyrBT44kvl9GfuralWEjt2NhE/63DWoKHaxmCFjmgHYaZlNGfkx92u6dL3/aVm efXFYNfKe0DA1G2YJByNDRGL/dQimW4MM2E5IjHjDq9aLbJUY/2Miqj/zmTNV5U2rASCRL 00mHzlwMSRM9+NnnUUZ6OcbquKg3SnuTyLYiEqNp+CqEZ1g4o+WK+MDbx4Rg+h7QgeWPGq f6Zq7lTrvIYX9dL0L+nUd01ngk0/VhOKUJtpgU7OOZ8mNz4YCjhWYgqnmH4zFZi0Qri0TH G1C29YYjWaT3wXY04eznq7RPHSatSNrHywAlw0ZiNdFWPTbipOWWZ9slxV/FYA== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (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 did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SZqqz3stmz1ccb; Wed, 22 Nov 2023 05:41:51 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 6C8AE27C0054; Wed, 22 Nov 2023 00:41:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 22 Nov 2023 00:41:51 -0500 X-ME-Sender:

X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehtddgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevufffoffkjghfgggtsehttd hmtdertddtnecuhfhrohhmpefrhhhilhhiphcurfgrvghpshcuoehphhhilhhiphesfhhr vggvsghsugdrohhrgheqnecuggftrfgrthhtvghrnhepgffgfeeigeettdeltdfgvedtff dtgedvheeuieetheetfeeifeevveetvddvkeegnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpodhmvghsmhhtphgruhhthhhpvg hrshhonhgrlhhithihqdduudeiiedviedvgeekqddvfeehudektddtkedqphhhihhlihhp peepfhhrvggvsghsugdrohhrghesthhrohhusghlvgdrihhs X-ME-Proxy:

Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 22 Nov 2023 00:41:49 -0500 (EST) From: Philip Paeps To: Robert Clausecker Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: Time to remove sccs tags Date: Wed, 22 Nov 2023 13:41:43 +0800 X-Mailer: MailMate (1.14r5999) Message-ID: <1CA7956B-8204-4328-A977-C874A3FAE0A7@freebsd.org> In-Reply-To: References: <22458D4C-35ED-4040-AAA1-A43006C0B32F@freebsd.org> 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; format=flowed On 2023-11-22 13:21:27 (+0800), Robert Clausecker wrote: > Am Wed, Nov 22, 2023 at 01:15:14PM +0800 schrieb Philip Paeps: >> On 2023-11-22 00:12:48 (+0800), Warner Losh wrote: >>> It's been 30 odd years since the last csrg release. They are no >>> more. >>> >>> At this point I think we can safely remove the few sccs tags that >>> remain >>> in >>> the tree. The data will be there in git if we ever need it. >>> >>> Comments? >> >> Long overdue. >> >> Since we're removing all these tags, should we also remove what(1) >> and >> possibly ident(1) from the tree? >> >> Removing what(1) should be non-controversial at this stage. I can >> imagine >> some people may still be using ident(1) on extant Subversion systems. > > what(1) is part of POSIX, though I guess you can just install > devel/sccs > if you need it. I think the only reason we still have what(1) is because it was once useful to (help) identify the provenance of a file. It wasn't very good at it in the past, and it certainly isn't very good at it now. In 2002, Juli tried to resurrect SCCS for POSIX/SUS compliance. It looks like the attempt was aborted before FreeBSD 5.0-RELEASE though... Anyone who needs to tick this box in their standards compliance paperwork should simply install devel/sccs. :) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From nobody Wed Nov 22 06:03:23 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 4SZrJp36PWz51vVd for ; Wed, 22 Nov 2023 06:03:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 4SZrJn73t1z4QjT for ; Wed, 22 Nov 2023 06:03:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a00191363c1so342662566b.0 for ; Tue, 21 Nov 2023 22:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700633000; x=1701237800; 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=AielLiRpfjFhEdlj/eUXxTEIpat27noXei1104dvrSo=; b=JRZlaA+aR5gNitmOqIbEpkFlqb+3J28tVuu/f5dZ3ZJ8BeFAeiJrx4uXjjWFOBp7d2 d1/q/bDXY/67OubI41B8Ck1+Rs1JvjI822+wMV6+0MISmJq7I9jxmXaYHa1erZDd8Dyj +sKe0njPTaKOZw+GLheGyu1fjiXjYl62KHRR77jZGbACs8ONbx7ySy2DIFf+QtW0pGRp j1OjSsZQXi6Jnb4eJHTBZ9s8SyFeO/3mPzyhsOCDhi6jEmxC4cwe/EQhzKpQtZSyBAOo Jb3sJ5CHnlY2o+YEA/vuQ3zKLcmFSqVMZhb7vv8R9xAnLifwdGjSgKTXr2oojdNII4IR KneQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700633000; x=1701237800; 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=AielLiRpfjFhEdlj/eUXxTEIpat27noXei1104dvrSo=; b=QBZOiPxvQsVE+s1TJiL+wm7o6XodVb4snlv5bPLHazn8mFq+K0GRGb29IdlIgfnIz+ LaAHw3KxcYUzOyCQRi5huqenwP429zOIOSsh5RatVGQZTeBxU8ffYzWIUj3tCMFmrk8r 30fK4g9VvDfzOvmYV05Gc8wwnZLY9ZaTTWiiy90D18r+JHCgQxp4UQ4oip/FhZtxrN3m S8reJdnuqsR1gsRn7Sdy1B0rJ/lzkbpzkNvUxyjP5beRqh20QGsBaHoPoJy1rDPcvVbb hemRNYRIQ1Z5dhpji7J+hM0kC2vEZcktHiArRSyHswup8oIuVqqOfJtfdsnzbU/x0yLo 1NJg== X-Gm-Message-State: AOJu0Yzh/uf67JczR52HQvI6Og5NxpOBQU0xzwj3q3/axs8vdzLa+k8U XYa7Mg8jwNbhOYYYL7tp2iVKcaxpNu3n4YtCuHgoJ4uB2/UCirIGb48= X-Google-Smtp-Source: AGHT+IEKHjlDoGnEXBvEXpijrAThmnrB/Tv9cU0mJ0+sno9JuarwdXE7rNmFdWyq9VUJhSDh/L64EmXMio0rY11MdXg= X-Received: by 2002:a17:907:d046:b0:9b2:6d09:847c with SMTP id vb6-20020a170907d04600b009b26d09847cmr912664ejc.10.1700632999698; Tue, 21 Nov 2023 22:03:19 -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: <22458D4C-35ED-4040-AAA1-A43006C0B32F@freebsd.org> <1CA7956B-8204-4328-A977-C874A3FAE0A7@freebsd.org> In-Reply-To: <1CA7956B-8204-4328-A977-C874A3FAE0A7@freebsd.org> From: Warner Losh Date: Tue, 21 Nov 2023 23:03:23 -0700 Message-ID: Subject: Re: Time to remove sccs tags To: Philip Paeps Cc: Robert Clausecker , freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d73597060ab7791d" 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: 4SZrJn73t1z4QjT --000000000000d73597060ab7791d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 21, 2023 at 10:41=E2=80=AFPM Philip Paeps = wrote: > On 2023-11-22 13:21:27 (+0800), Robert Clausecker wrote: > > Am Wed, Nov 22, 2023 at 01:15:14PM +0800 schrieb Philip Paeps: > >> On 2023-11-22 00:12:48 (+0800), Warner Losh wrote: > >>> It's been 30 odd years since the last csrg release. They are no > >>> more. > >>> > >>> At this point I think we can safely remove the few sccs tags that > >>> remain > >>> in > >>> the tree. The data will be there in git if we ever need it. > >>> > >>> Comments? > >> > >> Long overdue. > >> > >> Since we're removing all these tags, should we also remove what(1) > >> and > >> possibly ident(1) from the tree? > >> > >> Removing what(1) should be non-controversial at this stage. I can > >> imagine > >> some people may still be using ident(1) on extant Subversion systems. > > > > what(1) is part of POSIX, though I guess you can just install > > devel/sccs > > if you need it. > > I think the only reason we still have what(1) is because it was once > useful to (help) identify the provenance of a file. It wasn't very good > at it in the past, and it certainly isn't very good at it now. > what is not going anywhere: % what /boot/kernel/kernel /boot/kernel/kernel: FreeBSD 14.0-ALPHA3 amd64 1400097 #27 stable/14-n265023-7be29291845a: Sun Aug 27 12:46:22 MDT 2023 % > In 2002, Juli tried to resurrect SCCS for POSIX/SUS compliance. It > looks like the attempt was aborted before FreeBSD 5.0-RELEASE though... > > Anyone who needs to tick this box in their standards compliance > paperwork should simply install devel/sccs. :) > What also works with kernel core files. Warner > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > --000000000000d73597060ab7791d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Nov 21, 2023 at 10:41=E2=80= =AFPM Philip Paeps <philip@freebsd= .org> wrote:

On 2023-11-22 13:21:27 (+0800), Robert Clausecker wrote:
> Am Wed, Nov 22, 2023 at 01:15:14PM +0800 schrieb Philip Paeps:
>> On 2023-11-22 00:12:48 (+0800), Warner Losh wrote:
>>> It's been 30 odd years since the last csrg release. They a= re no
>>> more.
>>>
>>> At this point I think we can safely remove the few sccs tags t= hat
>>> remain
>>> in
>>> the tree. The data will be there in git if we ever need it. >>>
>>> Comments?
>>
>> Long overdue.
>>
>> Since we're removing all these tags, should we also remove wha= t(1)
>> and
>> possibly ident(1) from the tree?
>>
>> Removing what(1) should be non-controversial at this stage.=C2=A0 = I can
>> imagine
>> some people may still be using ident(1) on extant Subversion syste= ms.
>
> what(1) is part of POSIX, though I guess you can just install
> devel/sccs
> if you need it.

I think the only reason we still have what(1) is because it was once
useful to (help) identify the provenance of a file.=C2=A0 It wasn't ver= y good
at it in the past, and it certainly isn't very good at it now.

what is not going anywhere:

% what /boot/kernel/kernel
/boot/kernel/kernel:
FreeBSD 14.0-A= LPHA3 amd64 1400097 #27 stable/14-n265023-7be29291845a: Sun Aug 27 12:46:22= MDT 2023
%
=C2=A0
In 2002, Juli tried to resurrect SCCS for POSIX/SUS compliance.=C2=A0 It looks like the attempt was aborted before FreeBSD 5.0-RELEASE though...

Anyone who needs to tick this box in their standards compliance
paperwork should simply install devel/sccs. :)

What also works with kernel core files.

Wa= rner
=C2=A0
Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

--000000000000d73597060ab7791d-- From nobody Thu Nov 23 22:39:53 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 4SbtNG5w5Tz52Hjr for ; Thu, 23 Nov 2023 22:39:58 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 4SbtNF5pRyz4bsY; Thu, 23 Nov 2023 22:39:57 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=S1r+vYXN; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::52e as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5c186f027cfso858820a12.3; Thu, 23 Nov 2023 14:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700779196; x=1701383996; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=2ndv0kwmqWvE2IFYRt+Cjpq/NhsBUYV4gv1eVOQIFk0=; b=S1r+vYXNtyKinWOODzM9I1RS0uHGsSV1DSpQOS82fYIOuq8PjBxK/rsRvTxA7nbwdd wwQhq9tKfFQi0nFPb/0aWzPtpps7hvwfl7LfytOT9SzV4cTvNfJj1bwUqvNqtDI8fAzD HRHJVrbv9ayrGAvqnsHvCrvJNPxkOA0XvoJAo7bVwjgivhLr40SbW1rasC1EviZuHnWp kEzJYBR0UpYCEJQc/tSrMFbyup+3ricREhfF98dP8JFBxOdcMIRjRkk/mzpKJ2tuEBCh Dj2i4q2FHHuE8qsL/WORhDQgt4mtzneWdqeT4VZ33wuFoaRVh4s07ZPHNDz7FxGsx1bW u68A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700779196; x=1701383996; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2ndv0kwmqWvE2IFYRt+Cjpq/NhsBUYV4gv1eVOQIFk0=; b=Xh/dN/J64H0mgwoswoLPUp9cavT5ZKWP6/akcD521stHdGY8lOz0U8upaHQT5terxM XBQVI8TBinnecBR/m3DEBs/r1UzRHAaM7iMYOzsi0uCNFi8vCPrk3bNt72QJ5EMOnvbH bZrKrO7yopUtE2YQz6ftfof/99y6amqZP8/z8hhPnA7xLsA8UHiOkMffVNJtns0eUnzA 5zZLz/JQ2cHtaoGPXxgaOKwcmY5XGCw9cyUoAw5KI/XlnhRcspoBYaznp3J9+zyg81eu HZxo0mnkvrTJv/EVELlIJwo/63xFkDghhLPSoGmMgLPOMFR0PNygKzbnhkxpsDAvfNS3 eI2Q== X-Gm-Message-State: AOJu0Yxp8Q8DnStDHGzviRnBtpAUIqFDRm617b5omvV/qBm665ValUqs 8O3WnP5JtLliWDa0F345hlP6R3LBRExlVA== X-Google-Smtp-Source: AGHT+IHdN8pf6dTNvEt+tLfn3OM8JrDxqL/yhdT2EmVnw9qrkR3al1QAHVsPLdOFU0CJ/LTZGdBF1A== X-Received: by 2002:a05:6a20:430d:b0:187:5dd:16dc with SMTP id h13-20020a056a20430d00b0018705dd16dcmr1018906pzk.17.1700779195626; Thu, 23 Nov 2023 14:39:55 -0800 (PST) Received: from smtpclient.apple (c-73-35-248-51.hsd1.wa.comcast.net. [73.35.248.51]) by smtp.gmail.com with ESMTPSA id e3-20020a170902744300b001cf5d324817sm312286plt.188.2023.11.23.14.39.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2023 14:39:55 -0800 (PST) From: Enji Cooper Message-Id: <177E8235-05A2-4C16-A433-EBA02D3AC163@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D7848FA4-022E-4C55-81FA-69DC1784D702"; protocol="application/pgp-signature"; micalg=pgp-sha256 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: Time to remove sccs tags Date: Thu, 23 Nov 2023 14:39:53 -0800 In-Reply-To: Cc: Philip Paeps , Robert Clausecker , freebsd-arch@freebsd.org To: Warner Losh References: <22458D4C-35ED-4040-AAA1-A43006C0B32F@freebsd.org> <1CA7956B-8204-4328-A977-C874A3FAE0A7@freebsd.org> X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spamd-Result: default: False [-5.44 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.84)[-0.840]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52e:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SbtNF5pRyz4bsY X-Spamd-Bar: ----- --Apple-Mail=_D7848FA4-022E-4C55-81FA-69DC1784D702 Content-Type: multipart/alternative; boundary="Apple-Mail=_2751F455-FEDD-499C-BD76-331A2656D5A4" --Apple-Mail=_2751F455-FEDD-499C-BD76-331A2656D5A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 21, 2023, at 10:03 PM, Warner Losh wrote: >=20 > On Tue, Nov 21, 2023 at 10:41=E2=80=AFPM Philip Paeps = > wrote: > On 2023-11-22 13:21:27 (+0800), Robert Clausecker wrote: > > Am Wed, Nov 22, 2023 at 01:15:14PM +0800 schrieb Philip Paeps: > >> On 2023-11-22 00:12:48 (+0800), Warner Losh wrote: > >>> It's been 30 odd years since the last csrg release. They are no > >>> more. > >>> > >>> At this point I think we can safely remove the few sccs tags that > >>> remain > >>> in > >>> the tree. The data will be there in git if we ever need it. > >>> > >>> Comments? > >> > >> Long overdue. > >> > >> Since we're removing all these tags, should we also remove what(1) > >> and > >> possibly ident(1) from the tree? > >> > >> Removing what(1) should be non-controversial at this stage. I can > >> imagine > >> some people may still be using ident(1) on extant Subversion = systems. > > > > what(1) is part of POSIX, though I guess you can just install > > devel/sccs > > if you need it. >=20 > I think the only reason we still have what(1) is because it was once > useful to (help) identify the provenance of a file. It wasn't very = good > at it in the past, and it certainly isn't very good at it now. >=20 > what is not going anywhere: >=20 > % what /boot/kernel/kernel > /boot/kernel/kernel: > FreeBSD 14.0-ALPHA3 amd64 1400097 #27 stable/14-n265023-7be29291845a: = Sun Aug 27 12:46:22 MDT 2023 > % Brilliant =E2=80=94 what(1) definitely helped bring sanity to a = slightly complicated Unix golf one-liner at $work. Personally that=E2=80=99= s the only item I care about, but RCS/SCCS expanded keywords/tags seem = pretty much dead at this point (for better or worse). Cheers, -Enji --Apple-Mail=_2751F455-FEDD-499C-BD76-331A2656D5A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Nov 21, 2023, at 10:03 PM, Warner Losh <imp@bsdimp.com> = wrote:

On Tue, Nov 21, 2023 at 10:41=E2=80=AFPM Philip = Paeps <philip@freebsd.org> wrote:
On 2023-11-22 = 13:21:27 (+0800), Robert Clausecker wrote:
> Am Wed, = Nov 22, 2023 at 01:15:14PM +0800 schrieb Philip Paeps:
>> On 2023-11-22 00:12:48 (+0800), Warner Losh = wrote:
>>> It's been 30 odd years since the last = csrg release. They are no
>>> = more.
>>>
>>> At this = point I think we can safely remove the few sccs tags that
>>> = remain
>>> in
>>> the = tree. The data will be there in git if we ever need it.
>>>
>>> Comments?
>>
>> Long overdue.
>>
>> Since we're removing all = these tags, should we also remove what(1)
>> = and
>> possibly ident(1) from the tree?
>>
>> Removing what(1) should be = non-controversial at this stage. I can
>> = imagine
>> some people may still be using ident(1) = on extant Subversion systems.
>
> = what(1) is part of POSIX, though I guess you can just install
> = devel/sccs
> if you need it.

I think the only reason we still have what(1) is because it = was once
useful to (help) identify the provenance of a file. It = wasn't very good
at it in the past, and it certainly isn't very good at it = now.

what is not going anywhere:

% what /boot/kernel/kernel
/boot/kernel/kernel:
FreeBSD 14.0-ALPHA3 amd64 = 1400097 #27 stable/14-n265023-7be29291845a: Sun Aug 27 12:46:22 MDT = 2023
%

Brilliant = =E2=80=94 what(1) definitely helped bring sanity to a slightly = complicated Unix golf one-liner at $work. Personally that=E2=80=99s the = only item I care about, but RCS/SCCS expanded keywords/tags seem pretty = much dead at this point (for better or worse).
Cheers,
-Enji
= --Apple-Mail=_2751F455-FEDD-499C-BD76-331A2656D5A4-- --Apple-Mail=_D7848FA4-022E-4C55-81FA-69DC1784D702 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmVf1LkACgkQ5JFNMZeD GN74aw/8CyEmHF9wUH4XbtETUpwUHDMufwE6qamaK25ZYtHOwVYw98TMQ8RaWUvS lMQg5elshnh7RnMciNSFxYQJKXHbHADdO3uXH4C83fFeSmQrFZj+VOXW09Aj+pua YHNnvMEWQ9SRsCmG6NroL/N7qeGa5s8lHCTn5tNVq0X31eLrEBwIrZPGvnRVwgPL 2OT8IGNrGdhY6K4f6nVDxBiTEEav7ODF48qV0OIG3eHFwtDr25ppCnQTCNAEnWK1 AMw7v+07G8yMrAvjSGkNazCrfiJ3Ed5MIeeHlM1ogRquwoun4isW04qEi0yOzCaK nii08DHfRCzsiJD/5clfz63fFKqbvjl234HPRhYzx8/tCORFrzf9QlQ9kqcLfwir 74e24P5XjyCAuVM/P0g5OOCrvcXAVnLRXZ9hKylis4dfDfgEr9+lSLvsRggL/mdv G7TbCLdRtjfFiD5PGhC0H7iowmt2xaZln/O3NfOT2S59h9BHh8BXNQTIu5fz1r1Z BQocEtYY+6mvnHm9g/YLwQPEgSDoqY+IctViVSxMYxBF71OMJZgBMWwGaGH/Zlha Jla0Korj0MNJWjMZrt+qjlb9uaiSrE3KJPxTg2kZdKLWf0/adPg6J/pm+SQsjSmZ DopIvHs3W12o7m+jcJF1BDGziZeP3HY/Gfi724fNiAszN6OJSpU= =AEYH -----END PGP SIGNATURE----- --Apple-Mail=_D7848FA4-022E-4C55-81FA-69DC1784D702--