refactor: deprecate *MAX constants fitting #3131

[dybucc]

Description

Constants matching the *MAX naming scheme and whose purpose is that of denoting a limit among
other symbols have been deprecated in this patch. This stems from the deprecation efforts in #3131.

This is a follow up PR to #5120.

Notes

All of the sysconf constants have been ignored here because they themselves do not indicate value
that is a limit. Those constants, prefixed by _SC_, are meant to be issued to the sysconf()
library function, such that the actual limit is returned. The same applies to _PC_-prefixed
constants, which analogously apply to the pathconf() library routine. All of these limits are
supposed to be declared in limits.h by the target system's implementaion. Ofttimes, these are
actually meant to set a limit with respect to some system configuration, that is at least as large
as the POSIX-defined limit. I would like to ping here @JohnTitor (following from his comments on
[1]) and @tgross35, because I don't think these should be deprecated, but I could be wrong. Yes,
as per Chapter 11 of The Linux Programming Interface, these values can change at runtime (the most
concerning being the runtime increasable values), but I haven't been able to find out exactly which
of all constants that have a POSIX-defined limit should be deprecated. Should I just go for all of
those that are not classified as runtime invariant values?

Reading through the latest POSIX.1.2024 specification, it mentions in the limits.h file that there
is no guarantee that values that are not explicitly runtime invariant be read straight from the
limits.h macro definition without incurring possible runtime modifications [2]. It then goes on
to say that applications wishing for maximum portability ought use one of the afore-mentioned
library routines, among others. Considering setrlimit is itself used to change some of those
limits, I am lead to believe I should deprecate all constants that can be fetched by issuing one of
the _SC- or _PC-prefixed constants to sysconf or pathconf (or, for that matter,
fpathconf.) This, of course, should exempt those constants that are known to be runtime invariant.
The issue here lies in that it may very well be that some target system implementation we expose
through the libc crate does not necessarily adopt POSIX-compliance in this respect. Should I then
abide by the POSIX standard and call it a day? One example where this can lead to conflict is that
the TMP_MAX symbol was retired in Issue 6 of the spec, but that constant is still prevalent in a
number of the target systems we expose a C interface to. But this symbol predates even SUSv3, and
can only be found documented in SUSv2 [3]. Should we just follow the same path as we did with time
and file offset types, and go for the modern alternative? A different issue related to compliance is
the fact that some target environments allow modifying what are meant to be runtime invariant
values. This can be seen in NetBSD's implementation of sysctl, where AIO_LISTIO_MAX nor
AIO_MAX are not meant to be changeable, but [4] states they are.

I couldn't get a hold of the QNX sources. I got past their whole sign up and SDK request, but I once
I got to downloading the actual package from the so called QNX Software Development Center, the
binary would not launch. I tried in both Linux and Windows virtual machines, but I had no luck. No
constants that were not already specified in POSIX as not being runtime invariant have been modified
from their current state.

Also, the below notes on each source I've looked into contain some constants for which I have been,
for the time being, unable to decide on their deprecation for reasons outside those mentioned above.

Sources

• ELIBMAX is not the type of constant we would want to deprecate.
  This is just another enum-like "variant" for errno values. A concise defintion of its purpose
  is given in the below source, though this is not exclusive to Hermit.

  https://github.com/hermit-os/kernel/blob/38bff4ca8ca172039d1f6bee28cc0baa5183dd7c/src/errno.rs#L414

• Hexagon sources show that SIGRTMAX may be the type of constant we want to deprecate (sources can
  be found on the downloadable SDK.) This constant exists for the purposes of keeping a higher limit
  on the number of realtime signals that the system can issue. In theory, this is not defined in
  limits.h, and very much seems like a fitting "limit" value to be deprecated, but I have my
  doubts. Either way, this patch deprecates it.

• Linux sources show that the J1939_FILTER_MAX constant may be the type of symbol we would want to
  deprecate. Even though there's other _MAX-suffixed symbols in that module, the comment left
  alongside this one in the source code seems fitting of a "limit" value. This constant is
  documented in the kernel as being an upper limit on the number of filters that the J1939 protocol
  over CAN can configure. Considering the protocol is a higher-level abstraction, I am not sure if
  we can assume a certain degree of stability here, so I've deprecated it. But then again, I have my
  doubts.

  https://github.com/torvalds/linux/blob/8fde5d1d47f69db6082dfa34500c27f8485389a5/include/uapi/linux/can/j1939.h#L106

  https://www.kernel.org/doc/html/latest/networking/j1939.html

• NetBSD sources show that the MOD_PPSMAX constant is likely not one we would want to deprecate,
  as judging solely by the inline comment left alongside the symbol definition, it is meant to be
  used as an identifier to set an upper limit on some system config.

  https://github.com/search?q=repo%3ANetBSD%2Fsrc%20MOD_PPSMAX&type=code

• Linux sources show that, much like the above limit on filters for the J1939 protocol over CAN, the
  CAN_RAW_FILTER_MAX constant may be worth deprecating, as it seems to set the upper bound on the
  number of filters that one can set over raw CAN with a struct can_filter.

  https://github.com/search?q=repo%3Atorvalds%2Flinux%20CAN_RAW_FILTER_MAX&type=code

  https://docs.kernel.org/networking/can.html

• Hexagon sources show that the TMP_MAX and FOPEN_MAX constants are very similar to those
  symbols I decided not to deprecate in the limits.h header file of each target system's
  implementation. Their documentation in the downloadable SDK use the same wording and express the
  same purpose as other constants in limits.h, so I decided against deprecating those. These are
  actually part of SUSv2 (though FOPEN_MAX prevails in current versions of the standard,) and are
  supposed to be runtime invariant, so a user does not really risk anything by reading them through
  the value exposed in limits.h or otherwise through the sysconf library routine with the
  corresponding _SC-prefixed constants.

• All of the TeeOS _MAX-suffixed constants are part of those defined as the implementation limits
  for POSIX-defined constants, so those have not been modified. The same applies to a bunch of other
  implementations, such as those declared by the QuRT in their limits.h header file. At the
  moment, though, this only applies to those constants that have been known to be runtime invariant
  by any one of the SUSv2, SUSv3 or the latest POSIX standard specifications.

• The RLIM_SAVED_MAX constant, even though not quite the same as the other limits, is documented
  in The Linux Programming Interface, by Michael Kerrisk, as being a similar resource limit for
  applications where, say, one may have launched a process on some machine where a 64-bit resource
  limit is inherited but the process is being run in 32-bit mode (e.g. x86_32) is only capable of
  holding a potentially smaller resource limit. I believe this is not the type of constant we would
  want to deprecate.

• The BSD folks seem to do things a bit differently when it comes to limits that are used for
  kernel-relative requests to sysctl, but that does not mean the constants defined analogously to
  those in the limits.h header file have a different purpose (for the most part.) That's why I've
  decided against deprecating those we expose in the libc crate; Namely, KERN_IOV_MAX and
  KERN_ARGMAX. One exception to this is the KERN_SBMAX constant, which is not defined in terms
  of a constant in the POSIX standard, but the accompanying comments in the NetBSD source mentions
  as being used for the maximum size of a socket buffer; I've thus left it undeprecated.

  The same applies to some of the USER_- and CTL_-prefixed symbols. In this
  group, we do expose some constants that without the prefix actually match runtime increasable
  symbols specified in the POSIX standards.

  https://github.com/DragonFlyBSD/DragonFlyBSD/blob/59b78e44f96799c5f46fb3d6d616c18d838a75d0/sys/sys/sysctl.h#L531

  https://github.com/search?q=repo%3ANetBSD%2Fsrc%20kern_sbmax&type=code

• The FILENAME_MAX constant has not been deprecated, as that one seems to be part of the C
  standard library and seems to denote the largest supported character in an array of C chars.
  This likely makes it something folks can just read up, as there's no sysconf or (more
  appropiately, in this instance) pathconf constant to issue to these library routines to check
  the sure limit at runtime.

• The RTAX_MAX constant, unlike those mentioned above for the BSDs, is the type of limit we would
  want to deprecate, as it really only gives a size limit for arrays that are meant to hold all of
  the sockaddr values that are declared before it in the sources.

  https://github.com/search?q=repo%3ADragonFlyBSD%2FDragonFlyBSD+RTAX_MAX&type=code

  https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20rtax_max&type=code

• The NFSMNT_ACREGMAX and NFSMNT_ACDIRMAX constants are likely not the type of symbols we would
  want to deprecate, as those provide information in OpenBSD to fix the values of the last fields of
  the struct nfs_args. Though while looking into the source, I noticed we also expose from the
  libc crate the NFS_ARGSVERSION constant, which is documented as changing whenever the afore
  mentioned record changes. This is quite definetely worth deprecating, and this patch does so.

  https://github.com/openbsd/src/blob/42d9a1e328839c7e55d698ee9b8c6ce4dbb4628d/sys/sys/mount.h#L110-L162

• The FreeBSD sources show that the CMGROUP_MAX constant is likely not meant for deprecation, as
  the comment alongside its definition mentions that it's meant to be a limit on an actual resource
  and (to some extent) has historical significance. I believe this is not the type of constant that
  would be prone to fast changes, so I haven't deprecated it.

  https://github.com/freebsd/freebsd-src/blob/283959bbe0863917c4fc3200a92d1055a4c89bdc/sys/sys/socket.h#L506

• I am not completely sure of the RTP_PRIO_MAX constant in FreeBSD. It seems to denote the type of
  range fitting the constants we are deprecating, but it does seem to be used across the codebase to
  fix values relating to the rtprio family of functions. For the time being, I've left it
  undeprecated.

  https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src%20rtp_prio_max&type=code

• The MOD_PPSMAX constant is not fit for deprecation, as it's used as a "variant" for setter
  routine in the FreeBSD source.

  https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src+mod_ppsmax&type=code

• The SYS_-prefixed constants in Android are not meant for deprecation either. Those are used as
  "variants" to be issued to syscall() such that they may serve as identifiers for some other
  piece of functionality.

  https://cs.android.com/search?q=SYS_sched_get_priority_max&sq=&ss=android%2Fplatform%2Fsuperproject

• I'm having doubts about the PRIO_MAX constant in the Fuchsia and GNU Hurd trees. At first, I
  thought it would be part of constants defined in the POSIX standard like MQ_PRIO_MAX, where I
  decided against their deprecation so long as they were noted as runtime invariant in the spec. But
  looking at the Fuchsia source code, I am not so sure; It seems to be defined for compatibility
  with the Android Bionic source code judging by the file hierarchy, but it is not declared
  alongside other constants I would rather not deprecate. I would like some input on this from
  somebody else.

  https://cs.opensource.google/search?q=prio_max&sq=&ss=fuchsia

• I couldn't get hold of the AIX sources, but I assumed the same of the RTAX_MAX constant as I did
  in the BSDs, and went ahead and deprecated it. I could be wrong, though, as I've not had access to
  the upstream code. The same can be said of the BC_- and COL_-prefixed constants, both of which
  exist under the BSDs with an additional USER_ prefix. See the comments on those above. This also
  applies to the SIGRTMAX constant, which I did deprecate, as commented with the Hexagon sources
  above, and as explained in The Linux Programming Interface book.

• The AF_MAX and PF_MAX constants have been deprecated across all targets, as they seem to be
  used to denote the current limit on the procol and adress families after all other AF_- and
  PF_-prefixed constants.

• A constant that had breen previously marked as deprecated, AIO_LISTIO_MAX, has been undeprecated
  in favor of keeping deprecated solely the set of constants that are not runtime invariant
  according to the POSIX standard. This was discussed in the Notes section above.

• The SO_TS_CLOCK_MAX constant has been deprecated though it may just be that it should not be
  deprecated. This constant appears to me in the FreeBSD source code as being used solely for the
  purposes of denoting the largest of the constants defined prior to it, except for SO_TS_DEFAULT,
  which itself also takes on the values of one of the constants defined before it. I've taken this
  to mean that it's a "limit" value of the type we seek to deprecate. There's no mention of it in
  the POSIX standards either, so I've had to take a desision here that may have been the wrong one.

  https://github.com/freebsd/freebsd-src/blob/3118f1b99f23431235c202d9aadbe3d183bcc259/sys/sys/socket.h#L185

• The CPU_STATE_MAX constant in the XNU kernel was deprecated as it seems to be used as the
  maximum value that the possible CPU states can take on. Below its definition, the actual states
  are declared, with its own definition rounding up the size for, say, an array of such states.

  https://github.com/search?q=repo%3Aapple-oss-distributions%2Fxnu%20cpu_state_max&type=code

• The SCOPE6_ID_MAX constant in the XNU kernel has not been deprecated because it does not seem
  like it is a limit of any sort. There's neither any documentation on it beyond the comment left
  alongside its definition, which does not imply such use.

• I couldn't get any information on the SC_SPCM_MAX constant, because that is declared solely in
  AIX, and I can't get my hands on any AIX source code.

• I couldn't pinpoint the PR_SME_VL_LEN_MAX constant in the glibc repo, but I've decided against
  its depreaction because of the context that the kernel docs provide on similar constants
  (apparently related to vectored matrix operations on AArch64.) From my read on some of the
  sections (especially Section 6,) I believe this constant to be used as the maximum length of the
  SME vector length. This does not strike me like the type of "limit" we're trying to deprecate.

  https://docs.kernel.org/arch/arm64/sme.html

• After looking into the IN_CLASSA_MAX and IN_CLASSB_MAX constants in the GNU Hurd, I couldn't
  find those to be constants that we would want to deprecate, though in this particular instance, I
  would greatly appreciate if somebody else checked things out.

  https://cgit.git.savannah.gnu.org/cgit/hurd/glibc.git/tree/inet/netinet/in.h?h=t/sysvshm#n170

• I am not sure about deprecating the __SIGRTMAX constant in the GNU Hurd. This constant should be
  deprecated if we follow the same reasoning as explained in one of the above items. But this symbol
  is documented in the upstream source code as not being something users should call from
  application code. They should instead use SIGRTMAX as defined in signal.h. That one
  definition, though, we do not expose in the libc crate. I don't think the solution goes through
  adding that one constant and immediately deprecating it.

  https://cgit.git.savannah.gnu.org/cgit/hurd/glibc.git/tree/bits/signum-generic.h?h=t/sysvshm#n97

• I couldn't locate the TCP_COOKIE_MAX in the GNU Hurd codebase, so I've left it unmodified as I
  can't quite determine whether it should be deprecated or not without further context, and it does
  not seem to appear in any other supported target system.

• The RTLD_DI_MAX constant got deprecated, even though I couldn't locate it in the GNU Hurd source
  code, because that one has documentation on the constants that are declared right before it in the
  Linux manpages. I then assumed that the fact it takes on the largest value of such enum-like
  constants was enough to represent a "limit" constant prone to SemVer breakage.

• The following Android and Linux constants:

  • NFQA_CFG_F_MAX,
  • __NFT_REG_MAX,
  • NFT_MSG_MAX,
  • INPUT_PROP_MAX,
  • FF_MAX,
  • EV_MAX,
  • SYN_MAX,
  • KEY_MAX,
  • REL_MAX,
  • ABS_MAX,
  • SW_MAX
  • MSC_MAX,
  • LED_MAX,
  • REP_MAX,
  • SND_MAX,
  • PR_SCHED_CORE_MAX,
  • KERN_PIDMAX,
  • KERN_NGROUPS_MAX (no source because it's part of the runtime increasable values in POSIX)
    got deprecated following from the fact each of them are used as trailing enum values for the
    largest value of the constants whose suffix is not MAX.

  https://cs.android.com/search?q=NFQA_CFG_F_MAX&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=nft_reg_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=nft_msg_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=ff_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=input_prop_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=ev_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=syn_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=key_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=rel_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=rel_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=sw_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=msc_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=led_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=rep_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=rep_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=pr_sched_core_max&sq=&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/search?q=kern_pidmax&ss=android%2Fplatform%2Fsuperproject

• The PROP_VALUE_MAX constant in the Android source code did not get deprecated, as that seems to
  be meant for a limit on the length of some higher-level abstraction (judging by the comments left
  in the comments alongside it.) A related constant, PROP_NAME_MAX, serves a similar purpose and
  has not been deprecated, but may just be fit for deprecation as the Android sources themselves
  mention so in an accompanying comment.

  https://cs.android.com/search?q=prop_value_max&ss=android%2Fplatform%2Fsuperproject

  https://cs.android.com/android/platform/superproject/+/android-latest-release:bionic/libc/include/sys/system_properties.h;l=116?q=prop_name_max&ss=android%2Fplatform%2Fsuperproject

• The KERN_SHMMAX constant in the Android source tree is likely not meant to be deprecated. Even
  though not explicitly included among the runtime invariant values specified in POSIX, its use
  upstream does not seem like that of a "limit" value. If anything, it seems like an
  Android-speficic extension of constants similar to those specified as runtime invariant in SUS.

  https://cs.android.com/search?q=kern_shmmax&sq=&ss=android%2Fplatform%2Fsuperproject

• The M_MMAP_MAX and M_ARENA_MAX Linux constants were not found in the Linux source tree, so I
  have decided against their deprecation. I looked under include/uapi/linux/personality.h and
  didn't find anything. Then I looked into the glibc repo, and could neither find anything.

• The IFSTATMAX and TCP_FUNCTION_NAME_LEN_MAX constants in the FreeBSD source tree have been
  deprecated as the comments and context in their upstream definitions mention them as being used
  for character array sizes in fields of records declared near them. I believe this fits the type of
  "limit" value we're looking to deprecate.

  https://github.com/freebsd/freebsd-src/blob/2fa4bdd7f9e99698a6652db405c3165fdcd41c1d/sys/net/if.h#L550

  https://github.com/freebsd/freebsd-src/blob/2fa4bdd7f9e99698a6652db405c3165fdcd41c1d/sys/netinet/tcp.h#L472

• The TCP_BBR_PACE_SEG_MAX constant in FreeBSD has been left unmodified, because I couldn't find
  any context nor explanation on its purpose. The source code itself defines it as an unused
  constant.

  https://github.com/freebsd/freebsd-src/blob/2fa4bdd7f9e99698a6652db405c3165fdcd41c1d/sys/netinet/tcp.h#L271

• The PRI_MAX constant in FreeBSD has been deprecated, though I am not very sure of this one. It
  seems as if the range could change by the comment that precedes it and other related constants,
  but that may not be the case. One could interpret that the range bound to change is that of idle
  user threads, but I'm not sure. Outside input on this would be greatly appreciated.

  https://github.com/freebsd/freebsd-src/blob/2fa4bdd7f9e99698a6652db405c3165fdcd41c1d/sys/sys/priority.h#L87

• The SCTP_PR_SCTP_MAX and SCTP_ASSOC_SUPPORTS_MAX constants in FreeBSD (the former also in
  Linux) have been deprecated as they are used to denote the largest value among constants defined
  prior to them in an enum-like manner. This seems to fit the type of "limit" value we are looking
  to deprecate.

  https://github.com/freebsd/freebsd-src/blob/2fa4bdd7f9e99698a6652db405c3165fdcd41c1d/sys/netinet/sctp_uio.h#L262

  https://github.com/freebsd/freebsd-src/blob/2fa4bdd7f9e99698a6652db405c3165fdcd41c1d/sys/netinet/sctp_uio.h#L325

• The EAI_MAX constant in the Newlib tree has been deprecated because it also fits the trailing
  enum-like largest value mentioned in prior items.

  https://github.com/cygwin/cygwin/blob/6926523688bab730ae1b56f24ad6fb203b7350af/newlib/libc/sys/rtems/include/netdb.h#L184

• The _PTHREAD_SHARED_SEM_NAME_MAX constant in VxWorks got deprecated as the comment alongside its
  declaration implies it is used solely as a limit to character arrays for synchronization
  utilities. This seems like it fits the type of "limit" we would want to deprecate. Sources can be
  found in the VxWorks SDK for QEMU on x86_64.

• The _PARM_NAME_MAX and _PARM_PATH_MAX constants in VxWorks got deprecated because they seem to
  attempt to replicate the analogous, POSIX-compliant _POSIX_NAME_MAX and _POSIX_PATH_MAX, but
  using non-standard-compliant parameters set by them. The POSIX constants don't get deprecated
  because they're meant to provide a guarantee on the on the lower/upper bound of the constant
  they're referring, but these VxWorks-specific bounds do not seem to be backed by a standard, so I
  went ahead and deprecated them. Sources can be found in the downloadable SDKs for QEMU on x86_64.

• Much like in Android (as noted in one of the above items,) the PR_SCHED_CORE_MAX constant is
  used as a trailing maximum value for a set of constants delcared right before it in the Linux
  kernel's UAPI. This constant has thus been deprecated.

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/prctl.h#L290

• I couldn't find the RT_CLASS_MAX constant in neither of the Linux nor L4RE upstream repos, but I
  still decided to deprecate it as in our own sources (the libc crate) it appears to be a trailing
  enum-like value for the largest of some constants defined prior to it.

  libc/src/unix/linux_like/linux_l4re_shared.rs

  Line 1368 in 2364caf

  pub const RT_CLASS_MAX: u8 = 255;

• The SKF_AD_MAX constant in Linux has been deprecated as is used as trailing enum-like value
  denoting the largest of the "variants" declared before it.

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/filter.h#L82

• The following constants in Linux:

  • IW_ENCODING_TOKEN_MAX,
  • IW_POWER_MAX,
  • IW_RETRY_MAX,
  • IW_CUSTOM_MAX,
  • IW_GENERIC_IE_MAX,
  • KERN_RTSIGMAX,
  • KERN_SHMMAX,
  • KERN_MSGMAX,
  • SCHED_FLAG_UTIL_CLAMP_MAX
    have not been deprecated because they seem to be used as genuine maximum values unlikely to be
    changed, though I'm judging solely by the comments left alongside them and the overall context in
    the source code.

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/wireless.h

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/sysctl.h#L109-L112

  https://github.com/search?q=repo%3Atorvalds%2Flinux%20SCHED_FLAG_UTIL_CLAMP_MAX&type=code

• The FILNAME_MAX constant on Illumos has been deprecated as it was used as the array size for a
  field of a record declared right after it.

  https://github.com/illumos/illumos-gate/blob/6f3c184c6edfea99545c770c275f7d8680f05426/usr/src/uts/common/sys/socket.h#L219

• The TCP_RTO_MAX and PPS_SHIFTMAX in for Solarish-like systems constants were left
  undeprecated, as they denote a limit but they don't quite strike me like the types of values that
  would easily break SemVer.

  https://github.com/search?q=repo%3Aillumos%2Fillumos-gate%20TCP_RTO_MAX&type=code

  https://github.com/search?q=repo%3Aillumos%2Fillumos-gate+PPS_SHIFTMAX&type=code

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[rustbot]

Some changes occurred in an Android module

cc @maurer

Some changes occurred in an OpenBSD module

cc @semarie

Some changes occurred in a NetBSD-like module

cc @semarie

Some changes occurred in a solarish module

cc @jclulow, @pfmooney

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.