The set_constraint_handler_s function is specified to set the global process-wide runtime-constraint handler and return a pointer to the previously registered process-wide handler.
The default handler in place until the first call to set_constraint_handler_s with a non-null argument is implementation-defined.
One of the intended uses of set_constraint_handler_s documented in the TR 24731 Rationale is to let programmers temporarily replace the registered handler with ignore_handler_s that does nothing and simply returns to the caller (or a user- defined handler like it of their own), handle runtime constraint checking in their own code, and restore the original handler. This use case is particularly important in code that must avoid the risk of the constraint handler terminating the program, potentially abnormally.
However, since the process-wide handler is shared among all threads in a program, this use case isn't possible in multithreaded programs where pieces of code (either isolated functions or entire libraries often written by different teams of programmers with little knowledge of each others' implementation details) run in separate threads.
As a consequence, libraries or parts of large programs that cannot make assumptions about the effects of the registered constraint handler must be written to behave with predictable results regardless of whether or not the constraint handler returns. In particular, they must at the same time check and handle errors that could be returned by the bounds checking functions when a handler like ignore_handler_s is in effect, and also carefully save any persistent program state or flush buffers prior to calls to such functions in case the handler doesn't return. (A handler that terminates the program by calling _Exit or abort may result in the loss of program data.)
Since multithreaded programs are quickly becoming dominant, this restriction is a serious limitation of the APIs that makes using the APIs in such programs difficult and in some cases impractical.
In order to support the use case of temorarily replacing runtime constraint handlers in multithreaded programs, the standard needs to specify an API to set a per-thread constraint handler.
Changing the effects of set_constraint_handler_s to be per-thread rather than per-process would break programs that expect the current per-process behavior. However, a new function could be added, say set_thread_constraint_handler_s, to set a per- thread handler. The interaction of the new per-thread API with the per-process set_constraint_handler_s would need to be carefully specified and implemented to maintain the function's existing semantics while at the same providing sensible behavior in combination with the new function.
The suggested corrigendum stops short of outlining these semantics. If the committee decides that pursuing this approach is worthwhile, the author will submit a revision of this document with the specifics.