[mSparks]

"Safe/Secure" code - by definition must be slower than unsafe code.

Because every operation must pass over a series of hurdles to make sure it is safe. - does the code have permission to do this, is everything being supplied within bounds, is the system in a stable state.

Every language is about the same with all these checks in place. In fact C is quite possibly slower, because so many of the memory jumps will be so far away, and compilers are much better at optimising for this than people.

In my opinion not having these checks is only acceptable when the permissions of all developers and all users - potential and actual are identical. While there are rare cases this is true, much to many developers chargrin, in nearly every case it is not.

The whole point of SSL is that developers, users and users of the users permissions are totally different.

[DasIch]

This isn't true at all. The language has an impact on whether you can make perform these checks at runtime or at compile time. If you can do them at compile time, performance isn't affected at all and the code won't run slower.

[nickpsecurity]

"If you can do them at compile time, performance isn't affected at all and the code won't run slower."

That's not universally true. Compiler people tell me some optimizations happen using undefined behavior. Personal experience shows some, esp hand-optimized assembly, rely on stuff that a static analyzer just couldn't handle. These are common in compression, encryption, and multimedia libraries. So, you indeed might sacrifice performance writing code in a language that can knock out all kinds of problems at compile time working within the coding style it needs to do that.

In the general case, though, your point holds so far as lots of problems can be knocked out at compile time without affecting performance enough for the user to care.