But 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.

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?

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.

> 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.

No they couldn't.

> No they couldn't.

Elaborate? Why?

I elaborated in my first reply. Today's compilers don't have such a feature.

Nobody said they already do? I was saying they could implement it as an intrinsic.

They couldn't implement it in today's compilers unless they had a time machine. Today's compilers are already built and distributed and are what kernel developers use to compile their code today. I can't understand what you're finding so difficult about this.

> They couldn't implement it in today's compilers unless they had a time machine. Today's compilers are already built and distributed and are what kernel developers use to compile their code today. I can't understand what you're finding so difficult about this.

I am saying they could have either implemented this in the past (and thus had it land by now) or implement it now (and have it land in e.g. GCC in the near future). Neither appears to be the case. I was not suggesting they have a time machine. I can't understand what you're finding so difficult about this.

You're asking why they don't do it and I gave you an answer. If something different had occurred prior to today then the situation today could be different. But it's not, hence the situation we find ourselves in which you asked about, which is what I was helping you to understand.

You realize that implementing something is not the same as using it, right? Just like how cooking something is not the same as eating it? If they implement it today, they can use it tomorrow. I was asking "why don't they just implement the whole darn thing in the compiler" and your response was... because they don't have a time machine?

No, my response to that is because they are kernel developers, not compiler developers. For the nth time.

This really isn't rocket science. They need something that works in the kernel on today's compilers. The end.

> No, my response to that is because they are kernel developers, not compiler developers. For the nth time. This really isn't rocket science. They need something that works in the kernel on today's compilers. The end.

I have no idea how you make this stuff up, but Linux and GCC have thousands of developers working on them from all across the world, and Linux heavily takes advantage of GCC built-ins. There even exist active maintainers who understand and contribute to both... not that that is in any shape or form a requirement for putting out a request from one project to the other. The idea that they would've been unable to find a single person with sufficient interest & understanding of compilers to implement min/max in it is downright absurd. If they wanted to do this someone would have implemented it a long time ago. And yes, the end.

The kernel developers a writing code for the kernel, that has to be compiled with the compilers they have. Glad I was able to clear that up for you, you're welcome.