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.
