ojeda wrote: > Looking at Rust's arithmetic, there is just simply _no_ mismatched bit widths > allowed. Things need to be explicitly cast, so there is no ambiguity about > bit width. Going all the way to this requirement feels like the furthest > swing away from usability in C, especially with the goal of slowly adding > `__ob_trap` types/annotations to an existing codebase.
To be honest, not having to worry all the time about that in Rust is actually quite nice, and while skimming this discussion I felt it would be the simplest approach here too. But, yeah, some kernel developers may not be thrilled about it being an error -- it is very not-C-like. It would also require building the kernel often with a newer Clang, to catch all missing casts. It also feels a bit orthogonal to the overflow behavior (but since they do not behave the same anyway, it is a fair opportunity to introduce integers with less surprises...). https://github.com/llvm/llvm-project/pull/148914 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
