Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

[Paul Smith]

I have been trying to make clangd work with my GCC-based builds (it's a
long story don't ask) and after a ton of effort (and, unfortunately,
some hacks due to clangd limitations) there is one thing left that's
causing a lot of spurious errors:

In gcc/libstdc++-v3/include/bits/semaphore_base.h we find:

56  #ifdef SEM_VALUE_MAX
57      static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX;
58  #else
59      static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX;
60  #endif

Unfortunately because I am using limits.h from the clang intrinsics /
resource directory (else many other things break), _POSIX_SEM_VALUE_MAX
is not defined.  I can't quite figure out why, and my attempts to
generate preprocessor output to track it down through the #include /
#define maze have failed.  But the error I get (from clangd) suggests I
want to be using _SC_SEM_VALUE_MAX and indeed if I make that change it
works.

Should GCC be using the _SC version, since that's what's defined in
POSIX?

Or at least expanding the above to use it as a last resort, as in:

  #if defined(SEM_VALUE_MAX)
      static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX;
  #elif defined(_POSIX_SEM_VALUE_MAX)
      static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX;
  #else
      static constexpr ptrdiff_t _S_max = _SC_SEM_VALUE_MAX;
  #endif

??

Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

[Andreas Schwab]

On Jul 08 2023, Paul Smith wrote:

> Unfortunately because I am using limits.h from the clang intrinsics /
> resource directory (else many other things break), _POSIX_SEM_VALUE_MAX
> is not defined.

POSIX requires conforming implementations to define
_POSIX_SEM_VALUE_MAX.

> I can't quite figure out why, and my attempts to generate preprocessor
> output to track it down through the #include / #define maze have
> failed.  But the error I get (from clangd) suggests I want to be using
> _SC_SEM_VALUE_MAX and indeed if I make that change it works.

_SC_SEM_VALUE_MAX is related, but has a different role.  It is the
argument to sysconf to retrieve the runtime value of SEM_VALUE_MAX.

> Or at least expanding the above to use it as a last resort, as in:
>
>   #if defined(SEM_VALUE_MAX)
>       static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX;
>   #elif defined(_POSIX_SEM_VALUE_MAX)
>       static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX;
>   #else
>       static constexpr ptrdiff_t _S_max = _SC_SEM_VALUE_MAX;

That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not suitable
for a constexpr.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

[Paul Smith]

On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote:
> That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not
> suitable for a constexpr.

Oh right, obviously.

Well, I guess I'll have to try to figure out why it's not defined. 
Sigh.

Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

[Paul Smith]

On Sat, 2023-07-08 at 12:33 -0400, Paul Smith wrote:
> On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote:
> > That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not
> > suitable for a constexpr.
> 
> Oh right, obviously.
> 
> Well, I guess I'll have to try to figure out why it's not defined. 
> Sigh.

I figured it out.  I'm sure it's such a weird problem no one else will
hit it but just in case:

In order to use clangd without errors I need to use the clangd
intrinsics: clang can't parse the GCC intrinsics correctly.  The clang
limits.h uses #include_next <limits.h> which happens to find GCC's
include-fixed/limits.h and includes it in such a way that it doesn't
try to include the full system limits.h, so I only have the basics and
not all the POSIX extensions etc.

If I convince clangd to ignore BOTH the GCC intrinsics directory AND
the GCC include-fixed directory, then everything works as expected.