W.r.t.:

> Here, "set to" is
> probably something the resolution of Austin Group issue 1187 failed to
> fix; it should probably be "includes" rather than "is set to". But I'm
> not sure it makes sense to have any flags set alongside SS_DISABLE
> anyway.

While the SS_AUTODISARM flag has no effect if specified alongside SS_DISABLE, the kernel still accepts and stores it. So A subsequent call to sigaltstack can return SS_DISABLE|SS_AUTODISARM in the "old" flags value. To avoid the case where the old value returned from sigaltstack is not accepted back as the input, I used the "includes" semantics here.