From nobody Sat Sep 03 16:19:12 2022 X-Original-To: freebsd-current@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 4MKg313T76z4bpPm for ; Sat, 3 Sep 2022 16:19:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (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 4MKg302gRFz3fKl for ; Sat, 3 Sep 2022 16:19:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk1-f176.google.com with SMTP id a10so3838000qkl.13 for ; Sat, 03 Sep 2022 09:19:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=4950GfzXLuqs1VOJgflb2hHQLDLETSH3JYpRj3nLdOA=; b=gxzzh5XTaP+Qac6zykopqExWYs0ck73oQOxSBvxU+8NqydlizrVumhT6icbNYRyL9M pe+KyGUFXbj8sqzEqQJWIpPa1H6t3r+9geqDR3jeSffLhxoL+R18oqZqLpublpCX1CtB DkX1tF3+8rhXl6bIAUcPPz3ngxXQ7Xek6u88xDIM/H1R7KWAdvYOiRhw05Ttdk4hn4Cu T6aBWff/GjzuX8SPdzmF7gFUkjwoc+Hh8iMEUQ9QekF70B2c7NSeWvV8s+Wm01K0AJnQ 5F2g5E+w3sT+RVulTYcGYokDt81yoTIYzmfrR7XfLe9gS5jdPa7FwKReTxQRe8HmRLm/ JL2w== X-Gm-Message-State: ACgBeo1//ZlLnNnQa8rTn6P4G0aRLlfaFEFqDYkJMHsySKR+2fijXYNA s9VjuY/tgwi5dWfzln1jAnJFSKMo+lfJPOrfWpLzpi+rNcI= X-Google-Smtp-Source: AA6agR4mZmn9ZAPwmWzCHICUHojxQm9cLtA5qVCGa3c/ynUPLituXEbfwNd7BFo9rFl6Bkt2Prr+H/mO18cYXri1hIw= X-Received: by 2002:a05:620a:b04:b0:6ba:e707:b245 with SMTP id t4-20020a05620a0b0400b006bae707b245mr27655499qkg.418.1662221962841; Sat, 03 Sep 2022 09:19:22 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Sat, 3 Sep 2022 10:19:12 -0600 Message-ID: Subject: Header symbols that shouldn't be visible to ports? To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MKg302gRFz3fKl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.94 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.94)[-0.945]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.176:from]; FROM_HAS_DN(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.176:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; TO_DN_ALL(0.00)[]; FREEFALL_USER(0.00)[asomers]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Our /usr/include headers define a lot of symbols that are used by critical utilities in the base system like ps and ifconfig, but aren't stable across major releases. Since they aren't stable, utilities built for older releases won't run correctly on newer ones. Would it make sense to guard these symbols so they can't be used by programs in the ports tree? There is some precedent for that, for example _WANT_SOCKET and _WANT_MNTOPTNAMES. I'm particular, I'm thinking about symbols like the following: MINCORE_SUPER TDF_* PRI_MAX* PRI_MIN* PI_*, PRIBIO, PVFS, etc IFCAP_* RLIM_NLIMITS IFF_* *_MAXID Clearly delineating private symbols like this would ease the maintenance burden on languages that rely on FFI, like Ruby and Rust. FFI basically assumes that symbols once defined will never change. -Alan