Reply to post: Re: I'm done with Windows.

Re: I'm done with Windows.

Ohhh... I'm glad I came back here.

C is a great language and it's extremely diverse. It's absolutely horrifying for something like the Linux kernel though. Consider this, it has no meaningful standard set of libraries which means that support for things like collections and passing collections is a nightmare. Sure you have things like rbtree.[hc] in the kernel, but as anyone who has studied algorithms knows, there is no single algorithm which suites everything.

Let's talk about bounds, stacks, etc... there's absolutely no reason you can't enhance the C compiler to support more memory protection as well. C itself is a very primitive language and it's great for writing the boot code and code which does not need to alter data structures. But there are severe shortcomings in C. Yes, it's 100% possible to add millions of additional lines of repetitive and uninteresting code to implement all those protection checks. But a simple language extension could do a lot more.

Let's talk about where I find nearly all of the exploits in the kernel. This is in error handling and return values. It's amazing how you can cause problems with most code written at two different times by the same person or by two different people. The reason for this is that there's no meaningful way to handle error complex error conditions. Almost all code depends on just returning a negative value which is supposed to mean everything. The solution to this is to return a data structure which is basically a stack of results and error information and then handle it properly. The reason this isn't done is because people get really upset when implementing anything resembling exceptions in C. And yet, nearly every exploit I've found wouldn't have been there if someone implemented try/catch/finally.

Let's talk about data structure leaking and cleanup related to the above. Better yet, let's not... pretty sure that one sentence was enough to cover it all.

This is 2017, not 1969. In 2017, we have language development tools and technologies that allow us to make compilers in a day. This isn't K&R sitting around inventing the table based lexical analyzer. Sticking with the C language instead of creating a proper compiler designed specifically for the implementation of the Linux kernel is just plain stupid.

More importantly, there's absolutely no reason you have to use a standardized programming language for writing anything anymore. If your code... for example an operating system kernel would profit from writing a new programming language for it... do it. You can base it on anything you want. It's actually quite easy... unless you write the language itself in C. Use a language suited for language development instead. Get the point yet?

The next big operating system to follow the Linux kernel will be the operating system which leaves 95% of the C language in tact and implements a compiler which :

a) Eliminates remaining dependencies on assembler by implementing a contextual mode for fixed memory position development.

b) Provides a standard implementation of data structures as the foundation of the language

c) Implements a standard method of handling complex returns... or exceptions (possibly <result,errorstack>)

d) Implements safe vs. non-safe modes of coding. 90% of the Linux kernel could easily have been done in safe mode

e) Offers references instead of pointers as an option. This is REALLY important. Probably the greatest weakness of C for security is the fixed memory location bits. Relocatable memory is really really useful.If you read the kernel and see how many ugly hacks have been made because of it not being present, you'd be shocked. The Linux kernel is completely slammed full of shit code for handling out of memory conditions which exist purely because of supporting architectures lacking MMUs. References can be implemented in C using A LOT of bad and generally inconsistent code. It can be added to a compiler with a bit of work, but when combined with the kernel code, can implement a memory defragmenter that could fix A LOT of the kernel.

And since you're kind enough to respond aggressively, allow me respond somewhat in kind. You're an absolute idiot... though maybe you're only a fool. C# and .NET are actually very good. So is C, Java, C++, and many others. Heck, I write several good language a year when a domain would profit from it. I you don't know why C# and .NET or even better, Javascript are often better than plain C, you probably shouldn't pretend like you know computers.

Did you know that Javascript generally produces far faster and better code in most contexts than C and Assembler today? If you understood how microcode and memory access function, you'd realize there's a huge benefit to recompiling code on the fly. Consider that Javascript spends most of its time recompiling code as it's being run. This is because the first time you compiled it, it was optimal for the current state of the CPU, but as the state of the system changed (that's what happens in multitasking systems) the cache has changed and the CPU core being used may have changed (power state, etc..) and the Javascript compiler will reoptimize the code. It's even possible with Javascript that if you're on a hybrid system containing multiple CPU architectures or generations, the code can be relocated to a CPU which is better suited for the process.

Of course C could be compiled into Javascript or WebAssembly and have the same benefits. The main issue is that you lose support for relocatable memory as WebAssembly to support C/C++ is flat memory. But at least for execution, it's very likely your C code will run faster on WebAssembly than on bare metal. If you then start making use of Javascript/WebAssembly libraries for things like string processing, it will be even faster. If you move all threading to Javascript threading, it will be even better.

This does not mean you should write an operating system kernel in Javascript. Just as C is not suitable for OS development anymore, Javascript never will be.