Hacker News Reader

Comment by eventhorizonpl | Hacker News Reader

It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Ha! Fair point.

Two counter points:

* As other comments have mentioned, security bugs matter more in some products than others. (E.g. think of a desktop application connecting to an organisation's own database.)

* That includes a whole lot of code (maybe the majority) which is either C or C++ from before C++11, given that the bugs were tracked in the period 2006 - 2018. Never mind a hypothetical Rust-without-lifetimes.

70% of all security issues is not 70% of all bugs. For the large majority of software products, security issues are an infinitesimal minority of bugs, and arguably, for a significant chunk of software products, security issues are not even critical.

That's 70% of CVEs, not 70% of all bugs, which is a massive difference. Most programmers don't deal with CVE worthy bugs on a daily basis, no matter what programming language they use.

It's fact that it's easiest to cause a CVE bug in a language that you manually manage memory. So it's true that most likely JavaScript programmers may not cause them too often ;)

Anectodal, but: I had been working on a mixed C/C++ code base which grew over around 20 years to about 1mloc, with a team of programmers varying between 5 and 20, and we had to deal with memory corruption issues around once or twice a year, and those could be solved relatively quickly (even more quickly with modern memory debugging tools like the memory debugger/profiler in Visual Studio).

At the same time, the bug database for the project had a "throughput" of about 5..10 bugs per day (for the programming team, many more for the entire team). The amount of memory related bugs relative to "regular" bugs is infinitesimal even in a C/C++ code base.

Of course I realize that the code base had "sleeper bugs" that hadn't showed up yet, and a memory safe language would have helped to prevent those. But I just wanted to point out that memory corruption issues are just not a daily topic in most C/C++ projects.

In the end, safety comes down to the sandbox your code runs in (for instance operating system processes, or Javascript VMs). Should those sandboxes be written in Rust? Most likely yes. Should everything else be written in Rust? Nah...

Case in point, no? How many companies need to use a programming language with manual memory management?

This is why we need a professional organization to hold software developers accountable to the same standard as other fields of engineering.

I would love a world where that would happen; and also get years of testing, proof of concept time and funding to make all that actually happen. Not counting on it thoug since cost would skyrocket.

For this to work, you'd need most of the code to be written by people who are paid (i.e. professionals).

In my experience somewhere between 50-80% of code at most places is stuff pulled off maven/npm/github/etc written by people who are completely uncompensated, and possibly as hobby projects.

You could censure devs pulling in unverified code, but so far as I can tell, the vast majority of devs are really bad at reading code. I'm doubtful it would change anything.

This seems like something that should maybe covered in a computer science curriculum, but most colleges seem to have an aversion to becoming "job training" centers. If they don't start teaching it, I'm not sure how you can expect people to have training in it. Do we need a training course outside the traditional university system?

The problem with this idea has been the same for 40 years: unlike in other fields of engineering in Software there is no bedrock of empirical science from which we can derive objective, reasonable standards. It is all opinion in CS and no doubt the most obnoxious, useless methodologists would be the ones with the strongest opinions about how others should build things.

Well, software developers will need 2/3 years of legal training also then.

Both you and parent are correct. Memory safety issues in c++ code are common, but very often they don't manifest as segfaults. Malloc assertion failures or occasional data corruption in edge cases or "impossible" behavior are more typical symptoms.

Memory issues are rare in every C++ project I’ve ever worked on when compared to much more common bugs in expected functionality (the biggest category), bugs introduced by new or updated libraries, or operating system deprecations, etc.

Overall, the aversion to C++ and other non-GC languages is overly stated in the industry by vendors looking desperate for a problem to solve to validate using their new language or as a solution for companies that want to hire large armies of sub-par developers to bang on keyboards.

@hellokittycity

There are ideas like that

https://it.slashdot.org/story/22/06/13/0134242/two-tech-ceos...

This exactly.. we need to be able to have accountability. Agreed

Reply on news.ycombinator.com