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

There is no semantic difference between C++ and C in this area.

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.

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

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

Thanks,
Jens