On Monday, 8 June 2026 13:28:19 Pacific Daylight Time Michael Galuszka via Std-
Proposals wrote:
> My only reason for leaning toward keeping it is migration: Clang already
> ships [[clang::nonblocking]] with exactly this meaning, and libc++ has
> started annotating with it, so a divergent name would fork from a deployed,
> in-use spelling. That's a real cost, but I don't think it's decisive, and
> I'd genuinely rather land on a name people can live with than defend this
> one.

Yes, and when a macro was proposed for Qt for wrapping those, we had a
discussion whether we wanted to find a different name that would be more
specific, but ended up with just calling it "nonblocking".

I think the definition from the Clang manual is insufficient. They only talk
about locking resources (which malloc() in some implementations is), but in my
opinion that should be about blocking while waiting for some resource for an
arbitrary time. So, for example, if you try to read from a blocking pipe, even
though the total memory consumption is O(1), it's still blocking.

Now what happens if you put an upper limit on the wait? Since this appears to
have been designed for real-time analysis (RTSan), I would conclude it isn't
blocking because it will never block forever. But it might also not have
concluded the work - that might be the case of polling on the pipe with a
timeout before reading.

> So — does anyone have a spelling that says "signal-safe in the
> [support.signal] sense, as a checked property of the function type"

Those are so rare that TBH I've never thought they deserved markings. The
cases that need this are by necessity very small functions and can be easily
analysed by hand. BTW, there's an even more stringent category: safe between
vfork() and execve().

The way I see it, for this to be anything but niche for RTSan, it would need:
a) to be extensible with arbitrary tags
b) require a way to inform the analyser that a tag A implies B, so that we
don't need every function marked both
and possibly c) a way to annotate functions without modifying headers

For example, another marker is "this a pthread cancellation point", because if
cancellations are enabled and you call this function, your thread may die.
Glibc has a marker for this: noexcept(false), because everything else is
noexcept, and it uses the libunwind mechanism to cancel the thread and run
cleanups. But no other libc has any marker, and it might be useful to do an
analysis of cancellation-safety without having to modify the C library
headers.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.