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:
> > I'm trying to get at least a few small/trivial edits into our queue
> > for Hagenberg:
> >
> > https://cplusplus.github.io/CWG/issues/2970.html
> >
> > This essentially says that bit-fields of type volatile sig_atomic_t
> > don't get a special dispensation regarding data races in signal
> > handlers.
>
> 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.

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 ::