4 ms·

Refactoring for the sake of C pedantry rather than legitimate portability concerns is not a pragmatic approach. If this code were a part of some abstract "sphe

by eps 12y ago

Refactoring for the sake of C pedantry rather than legitimate portability concerns is not a pragmatic approach. If this code were a part of some abstract "spherical horse in vacuum" project that may potentially build on esoteric platforms using random C compilers, then, yes, it might be worth re-factoring. In the context of Linux kernel project given the toolchain used the code is perfectly fine as is. The debate is silly though, can't argue with that.

DominikD 12y ago
Linux kernel has official support for over 20 different ISAs. Some of the cores supported are pretty esoteric: BlackFin, SuperH, Etrax. Most of the problems with optimizing compilers - around UBs and others - come from architecture-specific optimizations. Problem discussed here is not abstract - people writing kernel code encounter these issues from time to time. I did, my friends did, we will be bitten by UBs in the future. Code my team is working on at the moment was written for a completely different architecture than it is run on right now. Sudden platform shifts happen, like when tsunami affected Renesas' ability to manufacture chips used in automotive. It IS pragmatic to avoid code that can potentially introduce problems in the future. Perhaps not for every piece of software, but low level one? Definitely.