[JohnFen]

> Aren’t most security vulnerabilities in C or C++ code?

I haven't seen any data that supports that idea, but I'm thinking it would depend on how you define "most". Do you mean in absolute terms? Then sure, because most code in use is C or C++ code. In relative terms? I have no idea.

But it's become fashionable to shit all over C these days as if C itself is a security vulnerability. I reject that idea. C certainly makes it easy to write insecure code. It's the flip side of the strengths of the language. However, there's nothing about C that prevents writing secure code in it (with the caveat that no code, regardless of language, can be considered 100% secure). That's done all the time.

[bsder]

> However, there's nothing about C that prevents writing secure code in it

C doesn't prevent you from writing secure code, but it sure as hell makes it hard.

I believe it was Bryan Cantrill who made the problematic observation that the main issue is that C code doesn't compose.

I can write a perfectly correct library. You can write a perfectly correct library. When somebody else brings those two correct libraries together, though, the result can be terribly broken.

This is where the GC languages and Ada and Rust kick C and C++ asses.

[jpc0]

There is this reasonably small C library used by literally the entire world that you may want to look into, the Linux kernel.

You may also note that in the general case even your beloved Rust and GC languages need to drop down to C the moment they want to interoperate with anything else.

[bsder]

> There is this reasonably small C library used by literally the entire world that you may want to look into, the Linux kernel.

WTF? The Linux kernel is gigantic. And is a prime example of non-composable fail.

Most functions fail in bizarre ways if you have re-entrancy. Out of memory is handled in myriad different ways--if it's handled at all. System calls can fail in a zillion ways with very little ability to recover correctly. I can go on and on.

[jpc0]

It was sarcasm...

Also the reason something can fail for any reason whatsoever is because the linux kernel cannot just decide to shut down your computer if a cosmic ray flips a bit while the cpu is reading from ram.

The reason you can write your small library is because of the work done.

Also the reason for my comment in general was the linux kernel is, in my opinion, the most used library on the planet and was and still is predominantly built on C.

Sometimes pretty APIs are not what you need. You need APIs that have been and will continue to do what needs to be done for decades

[spacechild1]

> However, there's nothing about C that prevents writing secure code in it

But it makes it exceptionally hard! Personally, I always try to use C++ over C for that reason (and many others). I also understand why some people prefer Rust.

[JohnFen]

> But it makes it exceptionally hard!

I suppose that depends on what you mean by "hard". I don't think it makes it exceptionally hard at all, but it does mean you have to actually think about the design decisions you're making. I also consider that to be a good thing -- we should be carefully considering our design decisions.

[spacechild1]

> I suppose that depends on what you mean by "hard"

Compared to all other languages (except for assembly :)

> but it does mean you have to actually think about the design decisions you're making.

I don't believe that. How does thinking about passing the correct number of bytes to realloc() or memmove() help you think about design decisions? It rather takes away mental energy for no apparant gain.