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