01.02.2021 07:58:26 Simon J. Gerraty <s...@juniper.net>:

> Martin Husemann <mar...@duskware.de> wrote:
>
>> [External Email. Be cautious of content]
>>
>>
>> On Sun, Jan 31, 2021 at 12:41:47PM -0800, Simon J. Gerraty wrote:
>>> David Holland <dholland-curr...@netbsd.org> wrote:
>>>> "static volatile sig_atomic_t reap_children;"
>>>
>>> I chose int (which is what sig_atomic_t is) for portability.
>>
>> No, it is not int - several NetBSD architectures use long.
>
> Sorry,  the one I checked as int, but I don't see that it should really
> matter?  int should be the type that any architecture deals with most
> naturally.

According to https://en.cppreference.com/w/c/program/sig_atomic_t, it has been 
available since C90, so don't worry about portability.

There might be architectures where atomic memory access must happen in units of 
64 bit. If you use a 32-bit int, this might result in load64 + mix + store64 
instead of a single store32 (at whatever implementation level of the memory), 
which is not atomic anymore.

Reply via email to