4 ms·

At this point you pretty much want an alternative language more than a compiler: one that looks like C, but is completely defined. And this makes kinda sense, y

At this point you pretty much want an alternative language more than a compiler: one that looks like C, but is completely defined. And this makes kinda sense, yet is IMO still quite dangerous (less than the actual situation but still too much) 1/ There are tons of people who will say: "this project is written in C" instead of the reality that is that this project is written in boringC, (actually probably even most of the projects authors will) and will for ex. compile with a regular C compiler instead of a boringC one, maybe for performance improvement... 2/ You just can't take C, even with a completely defined semantics, and call it a day for secure programming. It would still be filled with crazy features that are intrinsically impossible to render secure (everything about C "arrays" comes to mind) So let's take this idea to its real destination and rewrite secure projects using a really secure programming language, instead of just extending the current mess for 30 more years.

Gracana 11y ago
> At this point you pretty much want an alternative language more than a compiler: one that looks like C, but is completely defined. A "Friendly C" dialect has been proposed: http://blog.regehr.org/archives/1180 http://blog.regehr.org/archives/1180
aikah 11y ago
https://cyclone.thelanguage.org/ https://cyclone.thelanguage.org/ ? kind of ignored by the mass and unsupported now, yet this is exactly the kind of project the developer community needs... a language that is minimalist, yet with enough feature to allow some expressiveness and speed.
- dikaiosune 11y ago
  "(Several of Cyclone's ideas have made their way into Rust.)"
Terr_ 11y ago
So... Java? :P
fbbbbb 11y ago
So what do you do when an index into an array is out of bounds at run-time. You can't perform a check every time because that would go against the C's principle, and at the same time it would degrade performance, making it less useful compared to newer languages. How would you implement defined behavior without a significant (which is what an if check is at that level) overhead in this case?
- xorblurb 11y ago
  Compared to the economic cost of bugs, bound checks everywhere are (very very) cheap. Even more so with the CPU and compilers we have today, which are more than sufficiently smart from the point of view of when C was created. Intel is even adding some new instructions in their CPU to make that even less costly than you could imagine in even some crazy C based situation you would not think to be possible in the first place, because of C. But the cost here is extra complexity, for something that should have been built-in in the first place. More technically to address fears of slowdowns even with simpler architectures, the additional checks will likely be factored most of the time (for example before a loop with linear accesses). When they are not, to have a real impact 1/ it has to be in a really hot code path (like 1% or maybe even 0.1% or even less of a real system) 2/ the cpu should not be able to use empty OOO slots and execution units to execute it without any extra penality 3/ this is quite a deduction from the two preceding points, but if we are talking about a big array being accessed in random order this will be slow because of RAM access anyway, an extra check won't induce any meaningful slowdown maybe even if it were mispredicted (which it will not be - in regard to performance). Like always if you have any performance issue, first profile. And actually I can't remember having ever heard a single person complaining that some bound checking in a program was the cause of their slowdowns. It often far more macroscopic, and easy to fix anyway when it is that much micro. Considering usual modern systems, they are sometimes so slow that the problem is certainly NOT native bound checking, but very probably architectural madness.
  - Symmetry 11y ago
    If you were frequently catching out of bounds accesses your CPU's branch predictor would be making mistakes and you'd be frequently eating the branch mispredict penalty. Any extra instruction or check that alters the control flow is often much more expensive than just another addition. However, in this case if you're taking the branch something is seriously broken so that you should not be facing this. Pre-Haswell Intel CPUs only had one branch slot so you still might have a penalty but as you say this isn't the end of the world.
nickpsecurity 11y ago
Cyclone was already a good response. I'll add that you want one that's better than C and easy enough to port to. One that combines simplicity, fast compilation, fast execution, no undefined behavior, and plenty of safety. Fortunately, Niklaus Wirth and his people already implemented a half dozen or so of them. Plus industrial variants like Delphi (or FreePascal) and Modula-3. Safer, faster to develop, all used for OS's, most with GC, and fast enough in production. This of course assumes you won't use Ada, which eliminated most of safety issues as well. I doubt people will build on them. The dangers of C have too much allure. Plus all the code already written. ;)

Gracana 11y ago

> At this point you pretty much want an alternative language more than a compiler: one that looks like C, but is completely defined. A "Friendly C" dialect has been proposed: http://blog.regehr.org/archives/1180 http://blog.regehr.org/archives/1180

aikah 11y ago

https://cyclone.thelanguage.org/ https://cyclone.thelanguage.org/ ? kind of ignored by the mass and unsupported now, yet this is exactly the kind of project the developer community needs... a language that is minimalist, yet with enough feature to allow some expressiveness and speed.

dikaiosune 11y ago
"(Several of Cyclone's ideas have made their way into Rust.)"

Terr_ 11y ago

So... Java? :P

fbbbbb 11y ago

So what do you do when an index into an array is out of bounds at run-time. You can't perform a check every time because that would go against the C's principle, and at the same time it would degrade performance, making it less useful compared to newer languages. How would you implement defined behavior without a significant (which is what an if check is at that level) overhead in this case?

xorblurb 11y ago
Compared to the economic cost of bugs, bound checks everywhere are (very very) cheap. Even more so with the CPU and compilers we have today, which are more than sufficiently smart from the point of view of when C was created. Intel is even adding some new instructions in their CPU to make that even less costly than you could imagine in even some crazy C based situation you would not think to be possible in the first place, because of C. But the cost here is extra complexity, for something that should have been built-in in the first place. More technically to address fears of slowdowns even with simpler architectures, the additional checks will likely be factored most of the time (for example before a loop with linear accesses). When they are not, to have a real impact 1/ it has to be in a really hot code path (like 1% or maybe even 0.1% or even less of a real system) 2/ the cpu should not be able to use empty OOO slots and execution units to execute it without any extra penality 3/ this is quite a deduction from the two preceding points, but if we are talking about a big array being accessed in random order this will be slow because of RAM access anyway, an extra check won't induce any meaningful slowdown maybe even if it were mispredicted (which it will not be - in regard to performance). Like always if you have any performance issue, first profile. And actually I can't remember having ever heard a single person complaining that some bound checking in a program was the cause of their slowdowns. It often far more macroscopic, and easy to fix anyway when it is that much micro. Considering usual modern systems, they are sometimes so slow that the problem is certainly NOT native bound checking, but very probably architectural madness.
- Symmetry 11y ago
  If you were frequently catching out of bounds accesses your CPU's branch predictor would be making mistakes and you'd be frequently eating the branch mispredict penalty. Any extra instruction or check that alters the control flow is often much more expensive than just another addition. However, in this case if you're taking the branch something is seriously broken so that you should not be facing this. Pre-Haswell Intel CPUs only had one branch slot so you still might have a penalty but as you say this isn't the end of the world.

nickpsecurity 11y ago

Cyclone was already a good response. I'll add that you want one that's better than C and easy enough to port to. One that combines simplicity, fast compilation, fast execution, no undefined behavior, and plenty of safety. Fortunately, Niklaus Wirth and his people already implemented a half dozen or so of them. Plus industrial variants like Delphi (or FreePascal) and Modula-3. Safer, faster to develop, all used for OS's, most with GC, and fast enough in production. This of course assumes you won't use Ada, which eliminated most of safety issues as well. I doubt people will build on them. The dangers of C have too much allure. Plus all the code already written. ;)