C++ Logo


Advanced search

Re: [wg14/wg21 liaison] UB

From: Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
Date: Fri, 26 May 2023 23:06:28 +0200
on Fri, 26 May 2023 13:50:57 -0700 you (Hans Boehm <boehm_at_[hidden]>)

> On Fri, May 26, 2023 at 1:10 PM Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
> wrote:

> > More directly from the text follows that calling that `signal` in an
> > execution that has (had) multiple threads, is a fault. This was
> > what I was first thinking, too, but it may be more subtle than that,
> > actually. It is undefined what concerns the C standard, but it also
> > means that other standards such as POSIX may prescribe some specific
> > behavior here.
> >
> Posix doesn't have that restriction, though I think its wording is
> otherwise a bit obsolete.

That may be exactly the point. POSIX allows the use here. If C would
prescribe a fault, POSIX systems would not be conforming to C.

> I read the wording here as also prohibiting signal() if we later fork
> a second
> thread, with the motivation of dodging issues about where the handler
> runs. That would mean that "safe" visible side-effects would need to
> happen before the later of the signal() call and the initial thread
> creation.
> It would be good to clarify what was actually intended.

My guess is that there were quite varying implementations of signals
(and `signal` in particular) arround such that WG14 didn't wanted to
prescribe any behavior that these systems might have. (Or maybe was
just not able to find a consensus?)


:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Received on 2023-05-26 21:06:31