Re: Header symbols that shouldn't be visible to ports?

On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> 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.
_WANT_SOCKET is clearly about exposing parts of the kernel definitions
for userspace code that wants to dig into kernel structures.  Similarly
for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
definitions are guarded by additional defines not due to their instability,
but because using them in userspace requires (much) more preparation from
userspace environment, which is either not trivial (_WANT_SOCKET) or
contradicts to standartized use of the header (_WANT_MNTOPTNAMES + 
sys/mount.h).

> 
> I'm particular, I'm thinking about symbols like the following:
> MINCORE_SUPER
Why this symbol should be hidden?  It is implementation-defined and
intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
are under BSD_VISIBLE braces, because POSIX does not define the symbols.

> TDF_*
These symbols coming from non-standard header sys/proc.h.  If userspace
includes the header, it is already outside any formal standard, and I
do not see a reason to make the implementation more convoluted there.

> PRI_MAX*
> PRI_MIN*
> PI_*, PRIBIO, PVFS, etc
> IFCAP_*
These are all implementation-specific and come from non-standard headers,
unless I am mistaken, then please correct me.

> RLIM_NLIMITS
> IFF_*
Same.

> *_MAXID
This is too broad.

> 
> 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.

Why e.g. sys/proc.h is ever consumed by FFI wrappers?