=?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
jmorse wrote: Hi, Agreeing with @apple-fcloutier, another facet of this discussion is the fact that there are programming environments where the ship of Boolean-strictness sailed many years ago, and un-updatable, closed-source, illegal Booleans producing software exists which must be interacted with. As mentioned above and in the discourse thread, the Sony SDK environment is one of these -- it's not something we can discourage or negotiate away. This flag is a pragmatic fix to shield newly compiled code from software written in the past, without which we really do get crashes occasionally. I feel documentation and defaults is better for discouraging new illegal-Boolean environments, than mandatory undefined behaviour. Illegal Booleans being detectable by UBSan is a pretty good fence against the propagation of these values today, and gives a much better user experience when things go wrong than baking (permitted) assumptions into compiled code. https://github.com/llvm/llvm-project/pull/160790 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
