Possibly sounds like a bit of a design issue to me, author /assumed/ that reentrant mutexes wouldn't be added to the code, and this wasn't documented or tested for properly...
The memory safety problem isn't bad coders
51–60 of 225 posts
Re: The memory safety problem isn't bad coders
#52You shouldn’t rely on your tools protecting you because they won’t. I do part time work as an external examiner, sometimes for first year CS students, so I get to see a lot of silly code. Like the result of having been tasked with doing Fibonacci recursively. Which, as most of you no doubt are aware, can be done correctly in several different ways. The most basic is to simply implement it with its two base cases and…
If I saw somebody solving it with iteration I would be suspicious that they have a problem with recursion. Unless performance was part of the problem of course.
Re: The memory safety problem isn't bad coders
#53One thing that clouds the issue here is that it really is true that better coders do write fewer of these kinds of bugs. That's a real correlation and not a fictional thing.
So I think what we need to do is acknowledge that but keep it in perspective. While better coders write fewer security bugs, even the best programmers still write some. So it can't be our only line of defense.
Also, suppose for the sake of discussion it were true that top programmers did write zero security bugs. Realistically, as an organization, how would you ensure you employed nothing but exclusively these programmers? Even if you make it a top priority, you can't guarantee it.
Especially since the way you become a great programmer is by starting off as a less-great programmer and getting experience. And while you're doing that, you're churning out software which is by definition written by a less-great or not-yet-great programmer.
Re: The memory safety problem isn't bad coders
#54Earlier quoted context omitted.
Another take is that DESPITE there being a lot of 'amateurs' in the industry, the world generally seems to be humming along as normal, if not doing very well.
> Another take is that DESPITE there being a lot of 'amateurs' in the industry, the world generally seems to be humming along as normal, if not doing very well. Given that the count of software security incidents and data breaches are skyrocketing by all measures (e.g. https://www.varonis.com/blog/cybersecurity-statistics/ ), that's not remotely a reasonable view to take.
Data breaches are rarely correlated with amateur developers in my opinion. Breaches occur when a company makes financial decisions that it is cheaper for them to deal with the potential fallout of a leak than to prevent it in the first place.
More skilled labor won't solve this problem because it's fundamentally an issue of management and cost-saving measures.
Re: The memory safety problem isn't bad coders
#55No need to say 'bad', but there is definitely a shortage of experienced coders. - Competition/Compensation for experienced coders has risen sharply - There are many more inexperienced SDE's coming from colleges/bootcamps/etc - Senior titles are often given to individuals who are still very early in their careers Now, these factors might be necessary/good in the short term as software continues to eat the world. But,…
Way too many developers are working on proprietary implementations of what is fundamentally a content management system. We should be creating half a dozen of these things and doing a little light customization and a few addons. Instead have a couple, and devs look down on people who use them.
Either we are lousy at picking projects, we have a broken culture, or the problem is that we have too many developers and so people can ramp up a bunch of projects that have already been done hundreds of times elsewhere.
We’ve added lanes to the proverbial highway and traffic just gets worse..
Re: The memory safety problem isn't bad coders
#56Earlier quoted context omitted.
The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.
I don't really use auto unless I'm interfacing with some templatized nightmare body of code where the typename is very difficult for my tiny human brain to interpret. Using "auto" is usually a code smell, because it means your type system is too complex for you to reason about.
Not necessarily. The types may just have very long names. In C++ for iterating through STL container auto is a godsend. The types are very straightforward and easy to reason about but just long.
for (auto it = s.begin(); it != s.end(); it++) {
is much easier to write than
for (vector::iterator it = s.begin(); it!=s.end(); it++) {
Re: The memory safety problem isn't bad coders
#57In fact, I think it's the case that the most consequential security issues tend to come from the best programmers. That's because the best programmers tend to be the ones working on high-impact projects such as the Linux kernel. The more widely used the software, the more impact the security issues in that software have.
Re: The memory safety problem isn't bad coders
#58The problem here is the author’s development process. There’s an “old” programmer adage in regard to version control: merge early, merge often. It addresses the author’s issue directly. So yes, it’s not the code that’s bad. It the development process. Bad (ok, fine, inexperience) developer. https://queue.acm.org/detail.cfm?id=1643030
That's the point.
There is always something you haven't thought of (or did wrong), once you get to certain level of complexity.
Re: The memory safety problem isn't bad coders
#59Earlier quoted context omitted.
I don't really use auto unless I'm interfacing with some templatized nightmare body of code where the typename is very difficult for my tiny human brain to interpret. Using "auto" is usually a code smell, because it means your type system is too complex for you to reason about.
This is a valid, strongly typed C# object: var foo = {bar = 1, baz = “Hello”, boo = “World”}; You get auto complete help and compile time type checking. foo.bar = “Goodbye”; Won’t compile. What would it buy you to not use ‘var’ and create a one time use class/struct?
I use auto almost always. Makes the language "feel" more dynamic but you still have type safety.
Re: The memory safety problem isn't bad coders
#60> “The problem isn’t the use of a memory unsafe language, but that the programmers who wrote this code are bad.” This really goes to show how anti-worker the media is even among high-skill jobs. In my mid 20s I now mentor a bit in coding. I’ve worked with young devs that inherently know many of the obvious security pitfalls that have caused massive security breaches a la Equifax. Are devs at the front of these breach…
Well, although it could be anti-worker, it could also be one-upmanship among programmers with fragile egos: I'm not a bad programmer; they are.
And I think ego is a barrier to accepting tools that prevent errors. To accept the tool is to admit to yourself and others that you are going to make the error (sometimes) without it.