Jens,

on Tue, 21 Jan 2025 13:06:04 +0100 you (Jens Maurer
<jens.maurer_at_[hidden]>) wrote:

> On 21/01/2025 12.06, Jₑₙₛ Gustedt via Liaison wrote:
> > Giuseppe,
> >
> > on Tue, 21 Jan 2025 11:26:19 +0100 you (Giuseppe D'Angelo via
> > Liaison <liaison_at_[hidden]>) wrote:
> >
> >> Il 20/01/25 22:28, Jens Maurer via Core ha scritto:
> [...]
> >>
> >> While this sounds very reasonable, should we find some alignment
> >> with WG14?
> >
> > I would think so
> >
> >> AFAICS, N3435 only talks about objects of type `volatile
> >> sig_atomic_t`, and bit-fields are objects in C as well.
> >
> >
> >> Or this is about some multithreading clause that doesn't apply to
> >> C?
> >
> > yes, C does not claim the inter-thread synchronization properties
> > for `sig_atomic_t` such as C++ seems to have them. I don't think
> > that it has made its place on the list of incompatibilities between
> > C and C++, yet. I am surprised that such a change/addition to the
> > memory model sneaked in without confering with C, but may be this
> > dates from the dark times when we didn't speak to each other,
> > enough.
>
> > Perhaps it should be handled similar as in C++, but in general there
> > is a certain reluctance in C to put `volatile` and threads into the
> > same basket.
>
> > Nevertheless, injecting the same considerations for bit-fields also
> > in C makes perfect sense to me, even if we are just talking about
> > signal handlers. So I think it would be a good idea to put Hubert's
> > paper on the list for the liaison SG.
>
> There is no semantic difference between C++ and C in this area.

you mean concerning bit-fields? Yes, sure. This is why I am saying
that something similar to what Hubert's paper proposes would be
welcome for C.

> In WG14 N3435, the relevant rule is in 7.14.2.1 p5, and it just says
>
> "assigning a value to an object declared as volatile sig_atomic_t"
>
> without mentioning bit-fields as not having the special signal-safe
> property, either. There is also a bit of specification in 5.2.2.4 p5.

That's what I tried to say, sorry if I didn't make myself clear.

> Since this rule is a about stuff happening inside a signal handler,
> which is invoked at unpredictable times (unless invoked via "raise"),
> C++ has opted to integrate that rule into the multi-threading data
> race rule; see
>
> https://cplusplus.github.io/CWG/issues/1441.html
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3910.html
> https://cplusplus.github.io/CWG/issues/1961.html

And that's where there are huge differences. WG14 never made the
effort to integrate signals and threads. The only text that I have in
mind is the one for the `signal` function:

   Use of this function in a multi-threaded program results in
   undefined behavior.

I think, this is just our clumbsy way to say that this is an extension
point, because WG14 didn't wanted to restrict C++ or POSIX to build on
that model. But all of that is rather uncharted territory, in recent
years WG14 only has touched signals and signal handlers with a long
stick and a nose clip.

> Does WG14 have an issue tracker where I can report such issues when
> they're discovered on the C++ side?

We have, but it is private to WG14 because of copyright
scare. According to ISO policies it should at least be possible to
extend this to all SC22, I'd think. Perhaps we should talk to Robert
and David about this.

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA antenne de Strasbourg :::::::::::::::::: Camus ::
:: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::