Defining what happens when a bool isn’t 0 or 1

[AaronBallman]

@fay59

The nonzero and truncate options were introduced so that the community can assess impact on their preferred targets, and we can change the default for specific targets if that makes sense. In my experience, nonzero is typically what people expect, but the code for truncate on arm64 is slightly better in the worst case.

I don’t think the default behavior should depend on the target, that’s going to lead to some really hard-to-debug scenarios when going from a nonzero target to a truncate target. Personally, I think the default behavior should be nonzero for improved security; people who need the performance tradeoff on a target where truncate performs slightly better can opt into it. But I think that can also be hashed out on the PR rather than part of the RFC (I don’t insist on this approach, I just think it’s the more user-friendly option than what’s proposed).

@fay59

@AaronBallman, @efriedma-quic, bumping this again; Erich is asking to ensure that we have approval from the Clang area team for this.

The area team did not discuss this RFC specifically at our last meeting, so this is my personal reading of the thread – I think this has consensus to move forward. There may be some details to iron out during the PR review, but I don’t see any significant push-back on the idea or the direction it’s heading. I feel comfortable accepting on behalf of the area team.

[riking]

Replying to Richard Bieber on there: -fstrict-bool=trap seems like a valid future extension for Clang and an attractive alternate spelling for the existing GCC option.

We would call the existing behavior -fstrict-bool=ub .