[libcxx-commits] [PATCH] D81602: [libc++] Provide SEM_VALUE_MAX fallback on Solaris

[Rainer Orth via Phabricator via libcxx-commits]

ro added a comment.

In D81602#2087683 <https://reviews.llvm.org/D81602#2087683>, @ldionne wrote:

>




> Let's put it that way: as far as I can tell, this code is dead, so this patch isn't adding anything beyond technical debt. And the reason why it's dead is that there are no *libc++* build bots set up for Solaris, and no maintainer actively working on supporting that platform AFAICT.

True, because right now `libc++` doesn't build even on Illumos.  As I mentioned, my patch is only the first in a series to change that.
I'd have posted more of them already but for the pushback I got on the first trivial one.  While working on my patch series, I already encountered more of those (like AIX and partially Windows) that caused me to spend quite some time trying to verify that my changes wouldn't negatively affect them, only to discover in the end that the code doesn't even compile.

> JF made the comment he made because I recently complained to him about how the maintenance burden for libc++ is both huge and also rests on the shoulder of too few. The main reason for the burden being so large is that we try to support a high number of system configurations and sub-configurations of libc++ (like no-threads, no-stdio, etc.), and we also tend to bend backwards instead of requesting that systems conform to e.g. POSIX in a more stringent way. That's unfortunately part of a discussion that needs to happen and that is much larger than this patch, but my point is that libc++ needs to start dropping workarounds for systems that are not actively supported, not add new ones.

Fully understood: keeping code around for dead systems is only creating work for everyone else and making the code harder to maintain
for no gain.  However, demanding systems that conform to the very latest C and POSIX.1 standards quickly restricts you to a very small set: many people tend to forget that.

> Going back to the patch itself -- is there any reason why `<limits.h>` can't define `SEM_VALUE_MAX` on Solaris? That's the right way of solving this problem.

Yes and no: I'm discussing this very question with the Solaris engineers as we speak.  However, even if this were changed tomorrow, there's
a large installed base without that fix, so unless you restrict `libc++` to an (at least initially) neglegible number of systems, you have to allow
for those.  Besides, even if the choice of not defining `SEM_VALUE_MAX` is strange especially if the return value of `sysconf(_SC_SEM_VALUE_MAX)` is a constant, it's fully within at least the letter of POSIX.1/XPG7 which allows for that situation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81602/new/

https://reviews.llvm.org/D81602