Re: Should we standardize on a type for signal handler flags?

On 2017-06-06 14:13:29 -0400, Robert Haas wrote:
> On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I think that's a pretty good argument, really. If there exists a
> >> platform where only sig_atomic_t is safe to read from a signal
> >> handler, then we already don't work on that platform. Even saving and
> >> restoring errno isn't safe in that case.
> >
> > That's an argument from false premises. The question here is what types
> > are safe for an interrupt handler to *change*, not what can it read.
>
> OK, but we certainly have code in signal handlers that does:
>
> int save_errno = errno;
> /* stuff */
> errno = save_errno;
>
> If that's not a signal handler changing an int, color me confused.

Don't think it's actually clear that errno is an integer - might very
well be just a sig_atomic_t, which can contain values up to like 127 or
so. I think the bigger point Tom was making is that we actually know
an int4 is safe - otherwise we'd have crashed and burned a long time ago
- but that that might be different for *smaller* datatypes because
$platform doesn't really do smaller writes atomically (turning them into
read-or-write operations either in microcode or assembly). Alpha,
s390, pa-risc appear to have such behaviour cross-cpu - although that
doesn't necessarily imply the same is true for handlers as well.

A reasonable rule would actually be to only use [u]int32 and
sig_atomic_t, never bool.

- Andres