Secure? How?

[Combuster]

The idea that exploit mitigation is not worth bothering with is ... mind-bogglingly untenable.

Considering cyberwarfare is the future, intrinsic security like that is a worldwide asset. If you make it difficult or even impossible for developers to make certain classes of bugs, you basically improve the chances of surviving targeted attacks. Even if you know that an exploit will be found (which will happen, you can trust that), it certainly matters what the mean time is to find one.

In addition, having a head start and making it difficult enough also tends to convince (potential) attackers to just go for the easier target as well.

[no92]

It would be great if people actually had that mindset Combuster proposed - but we still suffer from a lot of unnecessary overflow and printf format string bugs. As I've lost faith in humanity some time ago, thus I don't think it'll get fixed by anyone any time soon, as it requires changes to standards. Remember, (stack) overflow attacks became a publically recognized problem in 2003 - that's when Windows XP was released. Don't get me wrong - these kinds of bugs are known for several decades, but except for some programmers, nobody was aware of them.

[SoulofDeity]

It would be great if people actually had that mindset Combuster proposed - but we still suffer from a lot of unnecessary overflow and printf format string bugs. As I've lost faith in humanity some time ago, thus I don't think it'll get fixed by anyone any time soon, as it requires changes to standards. Remember, (stack) overflow attacks became a publically recognized problem in 2003 - that's when Windows XP was released. Don't get me wrong - these kinds of bugs are known for several decades, but except for some programmers, nobody was aware of them.

This is why we need a new language to replace C. Especially because of the fact that the specification makes it impossible to have a standards compliant compiler for 8 or 16-bit architectures. Other languages keep trying replace C, but they fail because they mix systems programming and applications programming. The reason C works so well for systems programming is that it gets you as close to the metal as possible. There is no magic going on, what you see is exactly what you get. With applications programming, there's an added layer of abstracton between you and the system. Under the hood, when you call 'new' or use an overloaded operator, there is code being generated. Your class called Game.Object.Create may be called "_Z4NGame6CObject6uCreatev". If you want to replace C, don't be adding namespaces, classes, garbage collection, etc.

[no92]

We're back to what Brendan (I believe) said: one third of all bugs were caused by the programmer, one third is caused by the language allowing it and the programmer using the chance to "make use" of that bug and the last third is simply caused by the language itself, e.g. various overflows.

The solution you proposed is one possibility - you could also fix most of the problems with C, tough. By adding bounds checking to the compiler some security could be gained, at the cost of some clock cycles for checking things.

After all, your idea of replacing C is not bad - but the more backwards-compatible way would be to insert automated bounds checking and and kinda stuff.

[Icee]

With applications programming, there's an added layer of abstracton between you and the system. Under the hood, when you call 'new' or use an overloaded operator, there is code being generated. Your class called Game.Object.Create may be called "_Z4NGame6CObject6uCreatev". If you want to replace C, don't be adding namespaces, classes, garbage collection, etc.

None of these points applies to C, these are all C++ things. C and C++ are distinct languages with very different goals.

[HoTT]

With applications programming, there's an added layer of abstracton between you and the system. Under the hood, when you call 'new' or use an overloaded operator, there is code being generated. Your class called Game.Object.Create may be called "_Z4NGame6CObject6uCreatev". If you want to replace C, don't be adding namespaces, classes, garbage collection, etc.

• Name mangling is just there to be compatible to C.
• Calling an overloaded operator is the same as a function call via different syntax. No one would say that function shouldn't be used in C because they add an additional layer of abstraction between the programmer and the system
• classes in c++ are just a mechanism to bind a function at runtime, thus enabling inheritance / subtyping. It's useful, many C libraries emulate it by using function pointer.
• you might have a point with garbage collection

However only garbage collection relates to security by making memory safe code easier.

[SoulofDeity]

With applications programming, there's an added layer of abstracton between you and the system. Under the hood, when you call 'new' or use an overloaded operator, there is code being generated. Your class called Game.Object.Create may be called "_Z4NGame6CObject6uCreatev". If you want to replace C, don't be adding namespaces, classes, garbage collection, etc.

• Name mangling is just there to be compatible to C.
• Calling an overloaded operator is the same as a function call via different syntax. No one would say that function shouldn't be used in C because they add an additional layer of abstraction between the programmer and the system
• classes in c++ are just a mechanism to bind a function at runtime, thus enabling inheritance / subtyping. It's useful, many C libraries emulate it by using function pointer.
• you might have a point with garbage collection

However only garbage collection relates to security by making memory safe code easier.

Please keep in mind that I'm not condemning these features. They're useful, but should only belong in applications programming languages, not systems programming languages. When you're working close to the metal, there should never be any code generated or executed that the developer themselves cannot see. Trying to mix the 2 types of languages results in cruft and unnatural usage.

[HoTT]

Please keep in mind that I'm not condemning these features. They're useful, but should only belong in applications programming languages, not systems programming languages.

I don't see why name mangling only belongs into application programming languages. In regards to classes, the bitc developer are now convinced that every system programming language needs some kind of inheritance/subtyping.I think they're right (Example 1.2 is basically virtual functions implemented by hand).

When you're working close to the metal, there should never be any code generated or executed that the developer themselves cannot see.

So the code generated for a virtual function call does not belong to a system programming language, but the code emitted for normal function calls (prolog, epilog, parameter passing, stack management) is okay? Why draw the line there? What about macros? Wouldn't macros violate the rule as well?

[SoulofDeity]

Please keep in mind that I'm not condemning these features. They're useful, but should only belong in applications programming languages, not systems programming languages.

I don't see why name mangling only belongs into application programming languages. In regards to classes, the bitc developer are now convinced that every system programming language needs some kind of inheritance/subtyping. I think they're right.

When you're working close to the metal, there should never be any code generated or executed that the developer themselves cannot see.

So the code generated for a virtual function call does not belong to a system programming language, but the code emitted for normal function calls (prolog, epilog, parameter passing, stack management) is okay? Why draw the line there? What about macros? Wouldn't macros violate the rule as well?

Name mangling only belongs to applications programming because it's implementation specific and it obscures the use of functions from the developer. It's like saying,

Code: Select all

void kmain (void) __attribute__ ((alias ("main"))) {}

When the developer expects to call "kmain", but is being redirected to something different. In this case, there is a sort of inversion of control where the language is telling the programmer what symbol to use rather than the other way around.

The line is drawn between normal emitted function calls and virtual function calls because at that point, the programmer is still explicitly directing the control flow of the program. When you use virtual calls, you are relying on late binding; which implies there is a system underneath you controlling how things link together, rather than you being the one to control the system.

Yes, macros do break this system. You may be wanting to call 'printf' but a macro may replace that with 'pspDebugScreenPrintf'. In C though, the use of macro's is not part of the language, it's part of the preprocessor. Compiling C code is like translating your code 3 times. 'C+MacroProcessing -> C -> Assembly -> Machine Code'. (which is exactly what GCC does; *.c -> *.i -> *.s -> *.o)

EDIT:
I should add that the reason that macros are acceptable in systems programming are that they control the system from above rather than from below. They are always processed before compilation time, so behavior is deterministic.

[willedwards]

Now I happen to agree with 100% of Linus's rants even when I can think of exceptions that prove the rules. Take C++ for writing operating systems, for example... I have worked on kernels written in a restricted c++ and it worked great.

When the Go team first announced Go, they described it as a "systems language". They got roundly condemned for not knowing what a 'systems language' really was! Think about that for a moment... Rob, Ken and company ought to be able to define these kinds of terms?

[SoulofDeity]

Now I happen to agree with 100% of Linus's rants even when I can think of exceptions that prove the rules. Take C++ for writing operating systems, for example... I have worked on kernels written in a restricted c++ and it worked great.

When the Go team first announced Go, they described it as a "systems language". They got roundly condemned for not knowing what a 'systems language' really was! Think about that for a moment... Rob, Ken and company ought to be able to define these kinds of terms?

My understanding is that a systems language can directly manipulate memory or hardware, has static typing, and is fully deterministic at compilation time. An applications language can use static or dynamic typing and is fully deterministic at run time. A scripting language has dynamic typing and can be non-deterministic.

C++ is a grey area. As a whole, it must be considered an applications language. If you restrict yourself to using a subset of the language functionality, then it can be used for system programming. But you pay a price for that. To connect the two language styles, you have to create complex wrappers. Systems languages interact with memory directly so they use pointers to addresses to operate on data. Applications languages abstract themselves away from memory so they use handles of instances to operate on objects. Scripting languages then abstract away the idea of contained data altogether where everthing is variant and code may dynamically be altered at runtime (eg. the JavaScript eval function operating on strings)

[HoTT]

My understanding is that a systems language can directly manipulate memory or hardware, has static typing, and is fully deterministic at compilation time. An applications language can use static or dynamic typing and is fully deterministic at run time. A scripting language has dynamic typing and can be non-deterministic.

I am not sure if you know what deterministic means.

fully deterministic at compilation time.

Care to explain what that means?

[SoulofDeity]

My understanding is that a systems language can directly manipulate memory or hardware, has static typing, and is fully deterministic at compilation time. An applications language can use static or dynamic typing and is fully deterministic at run time. A scripting language has dynamic typing and can be non-deterministic.

I am not sure if you know what deterministic means.

fully deterministic at compilation time.

Care to explain what that means?

Deterministic means that there is no randomness involved. To be deterministic at compilation time means that what you see is what you get, there will be no code underneath you moving things around like threads or linking virtual functions. Deterministic at run time means that the overall behavior can be determined at run time. Note that this means that languages that use garbage collection like C# and Java also occupy a grey area between applications programming and scripting.

[HoTT]

Deterministic means that there is no randomness involved. To be deterministic at compilation time means that what you see is what you get, there will be no code underneath you moving things around like threads or linking virtual pointers.

That contradicts itself. Virtual pointers are no source of randomness. Virtual function calls are deterministic.

[SoulofDeity]

Deterministic means that there is no randomness involved. To be deterministic at compilation time means that what you see is what you get, there will be no code underneath you moving things around like threads or linking virtual pointers.

That contradicts itself. Virtual pointers are no source of randomness.

Yes, they are. The actual function being called is not known until run time. It can belong to anything that inherits from the base class.