4 ms·
For everyone with a “why don’t they just…?”-type suggestion, it’s worth carefully rereading TFA and considering what the macros do now and the problem they are
by seanhunter 2y ago
For everyone with a “why don’t they just…?”-type suggestion, it’s worth carefully rereading TFA and considering what the macros do now and the problem they are trying to solve.
The macros now do type-safe comparisons that work correctly with combinations of different argument types where this is possible, work in a constant context (eg defining array bounds), work correctly in the face of implicit type coercion and include a 3-way min and max that have these same desirable properties (same as the two way min and max).
The problem(s) are it’s a bit slow to compile and the preprocessor expansion (although not necessarily the final generated assembly - didn’t see anyone saying that) is a bit bloated.
So when you make a “why don’t they just…. ?”-suggestion, make sure your suggestion is at least as good as what they have now in terms of the desirable functionality and correctness and then tackles the actual problems in some way. I’m not sure all of the suggestions I have seen here and in the lwn comments succeed at meeting those two criteria.
- deleted 2y ago[deleted]
- dataflow 2y agoI have a "why don’t they just" question: if they're going to rely on compiler intrinsics anyway, why don't they just implement the whole darn thing in the compiler and do whatever they want there? If you're going to marry your code to the compiler, at least take full advantage of it?
- seanhunter 2y agoI think that’s an excellent suggestion tbh (and could meetmy two criteria as well) and someone may well do that. The thing they want seems perfectly reasonable to me and wouldn’t only benefit the kernel.
- starspangled 2y agoAssuming good faith, they don't do that because they are kernel developers not compiler developers, and they want it to build on the compilers that real systems have at hand. If somebody proposed a new extension and got llvm and gcc to both implement it today, they would still need something to work on old compilers. The oldest GCC supported by Linux is 10 years old nearly.
- dataflow 2y agoBut for older compilers they already have something that compiles correctly for valid inputs, no? They don't need e.g. the type-safety-check nonsense for that. The newer compilers will still catch mistakes in the usage sites via the intrinsics.
- starspangled 2y agoFor today's compilers they have something that compiles very slowly and they want the type safety checks because those are the ones the kernel developers use. That answers the original question doesn't it? If a new compiler extension was proposed and implemented and released in both llvm and gcc, some years after that they could drop support. But there would be no real imperative to drop support early since they will already have developed some code that works okay on those toolchains.
- dataflow 2y ago> For today's compilers they have something that compiles very slowly and they want the type safety checks because those are the ones the kernel developers use. That answers the original question doesn't it No, the point was for today's compilers they could have something that compiles quickly and does everything they want.
- starspangled 2y agoNo they couldn't.
- dataflow 2y ago> No they couldn't. Elaborate? Why?
- starspangled 2y agoI elaborated in my first reply. Today's compilers don't have such a feature.