OSDev.org

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

no92 wrote: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 wrote: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.

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

HoTT wrote:

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.

HoTT wrote:

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?

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

willedwards wrote: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.

fully deterministic at compilation time.

HoTT wrote:

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

HoTT wrote:

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.