=?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]>
apple-fcloutier wrote: @workingjubilee, "dialects" like -fno-strict-aliasing, -fno-strict-enum were not invented first and adopted later: they recognized existing misunderstandings and mistaken practices and put an upper bound on how screwed you'll be if you keep doing them. -fno-strict-bool follows in that tradition and is a reaction to people being careless with bools in existing codebases. At the risk of asking a silly question, are you sure that what inconveniences Rust is -fno-strict-bool? `Option<bool>` cannot be represented in C, so there's no risk of getting that one wrong at the ABI. You can get your `bool` values wrong at the ABI, but that is **currently** the case. -fno-strict-bool does not allow people to store bit patterns other than 0 or 1 in a `bool` (things like `bool b = 2` still put 1 in `b`), it limits how bad it can get if somebody made a mistake. This has several important facets: * It protects your users against your own mistakes in the same code base * It protects your users against mistakes in code that you share your address space with * You generally cannot know whether all code in the same address space (or even the same project!) was built with -fno-strict-bool Regarding point 1, Rust code ostensibly doesn't need to be paranoid about other rust code in the same address space like C kind of does. Because of point 3, it seems improbable to me that -fno-strict-bool can ever be interpreted as giving license to put any bit pattern you want inside of a `bool`, and as I [argued](https://github.com/llvm/llvm-project/pull/160790#discussion_r2582783118) with Aaron up in this thread, for ABI compatibility, you still need to consider it's UB to put a value that isn't 0 or 1 in a bool. Which leads me to the kicker on point 2: if clang finds it useful to protect itself against these mistakes, what is the case that Rust shouldn't? As far as I can see, the argument so far is that clang shouldn't because Rust wouldn't. My opinion is that the argument that Rust is doing the right thing up to now is rather weak: > Rust has been able to pervasively rely on such strictness because it has been > the practical, observed behavior of C and C++ programs for a long time, and > conformant to our readings of the C standard. Asking for evidence to back this claim up would be to ask for a proof of inexistence, which we both know cannot be produced. On the other hand, we do have evidence in the form of bug reports, at least internal to Apple and Sony (although some may be public), that in practice people _do_ carelessly handle `bool` values. This commonly-ish happens when people `memcpy` contents over structs containing `bool` values. Faced with security professionals insisting this is a problem, and the [RFC's clear demonstrations](https://discourse.llvm.org/t/defining-what-happens-when-a-bool-isn-t-0-or-1/86778) of how this leads to security issues, can you elaborate on: * What is the case that Rust is doing the right thing? * If we cannot make the case that Rust is doing the right thing: do you still think, after reading our own discussions around whether -fno-strict-bool has an effect on a platform ABI, that it actually does; and that mixing-and-matching -fno-strict-bool code is tolerable to clang but not tolerable to rust? I know you said `Option<bool>` reserves another bit pattern, but `Option<bool>` isn't representable in C, so it's not obvious to me what complexity this adds to the problem. https://github.com/llvm/llvm-project/pull/160790 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
