This is the thing - it's NOT super human. It's not even difficult. It's nothing more than learned behavior. I, for example, just had the advantage of having employers pay me to learn this stuff on the job.
Debugging a C++ template crash is difficult. Finding out why the Windows TCP stack does certain things is difficult. Writing clean and non-memory-over-writey 'C' isn't even close to those.
I have no idea what kinds of apps you're writing where it's that easy. Most apps with widespread use do complex things with code integrated in from many styles and skill levels of programmer. They have to get code cranked out quickly to meet deadlines. In the process, someone slips up with a pointer, array, whatever.
This has been true for many projects done by experienced C programmers. Hence, if not superhumans, then writing safe/secure C in such circumstances takes unusual talent. Whereas, it's effortless for people using something like Modula-3 to avoid most of those problems. By design. And checking for fools that turned it off is easy to automate: text search for "UNSAFE."
Hi nick! I don't know how to describe what it is I do. For lack of a better rubric - "embedded". Frequently, large things are involved, large things with diesel engines.
Shipping bugs is always an option. I'm pretty adamant about not doing that any more than I have to. And I work fast enough that this isn't a problem - most of that is that I know how to code & test very quickly. But there's furniture in the code to check for the usual 'C' bug suspects.
And yes - "hell is other people's code." This is why I try very very hard not to leave these sort of bugs around, build test fixtures and do other things to defend myself. I have used static analysis now and again. It's kind of nice.
Again, and again, and again, dysfunctional organizations abound and it's possible to avoid them altogether. But first you must earn to identify them.
It would be absolutely fascinating to work with a security pro to see how I'm doing. Right now, that's not in the cards.
"For lack of a better rubric - "embedded". Frequently, large things are involved, large things with diesel engines."
That's actually pretty cool as I'm gradually learning more about embedded systems. The problem with subversion and INFOSEC was the hardware on up. Got ASIC methodology done. Gotta learn embedded. You do control systems, CAN's, and dashboards for construction hardware and 18-wheelers or something? Generators at datacenters? Ok, I'm running out of ideas as I only think about diesels so much.
re rest
It looks like your an outlier in my overall claim. The reason is that you've picked a field and specific companies that let you do pretty custom work that's mostly your code at the quality level you prefer. Good for you. It just doesn't negate anything I said about getting C right in general. Your circumstances and effort just make you an exception to the rule. :)
We'd chatted before - for some reason your handle is mnemonic :)
I'd just as soon not be specific if you don't mind. And in the past it's been wireless, data collecting, even point of sale. Longer past, databases and such.
Your last paragraph is spot on. I'm a tiny mote in the overall cost structure, there's a healthy risk aversion and lead times favor good practice. The downside is - I don't have much cover when things don't work.
I'm sympathetic to the plight of people dealing with this, and have the conceit ( probably misplaced ) that I can offer encouragement.
"We'd chatted before - for some reason your handle is mnemonic :)"
I figured but memory looses stuff. I tried to make my email handle mnemonic for lay people and technical alike. Rare success. It was accidental if it happened for nickpsecurity handle.
"I'd just as soon not be specific if you don't mind. And in the past it's been wireless, data collecting, even point of sale."
Wireless collection of emissions for Volkswagon[1]. Yes, I understand the need for confidentiality and keeping emails from the person giving the orders. We'll move along.
"there's a healthy risk aversion and lead times favor good practice."
Well, that's good. The lead times being an enabler for software QA is a good thing to remember. The "release early, release often" companies might be harder to get onboard with QA. Don't need glacial cycles but at least a few months to work out bugs on significant features.
Come on, if it were that easy we wouldn't have so many security bugs that can be directly traced to some memory corruption issue.
Do you think that for example the Firefox developers are either too stupid to do it right or that they just don't care about security or maybe that it's a harder problem than you claim it to be.
The Firefox developers are very good professionals that came to the conclusion that all the tools they devised to write memory safe C and C++ aren't enough for writing a safe browser and a new start in the form of Rust and Servo is needed.
The Firefox roadmap already has plans for incrementally add code written in Rust.
That's good news as I still use Firefox. Btw, are there any good docs or blog articles on how it integrates into C or C++ code so well? I don't often see that in new languages. Leads me to wonder if there's lessons to learn there for another project.
A lot of it is simply that Rust has an equivalent amount of runtime to C and C++, so you don't have two runtimes fighting with each other. For example, when Rust had green threads, interop was much worse, due to needing to switch to a C stack, as well as the actual initialization of the runtime itself. Without it, it's as straightforward as https://news.ycombinator.com/item?id=11622257
That's what I'm saying. I refuse to call people that build things like Firefox incompetent. Apparently, there's intrinsic difficulty to using the language both productively and carefully at the same time.
Note: Firefox is coded in C++, though. Rather than contradictory, that what you say is still true given C++ is a safer, more organized C they still can't use safely.
I am prepared to call anyone who ships bad code incompetent. We are ALL incompetent at some level, and perhaps on some days.
Narrow is the way. You have to look them in the eye and say "It's not ready. You can force me, but you will first provide documentary evidence of that force ( an email prints off just fine ) and by the way here's what you're risking and do try to keep up."
And I am dead serious, folks. This is what it will take. It will take each and every contributor making it his/her personal mission as if it was their Klingon honor. The culture right now doesn't even know how to ask for that.
Right now, it looks like we can barely even have a conversation about it.
Id love to see Modula-<n>, or Rust, or anything else used. But the logistics of that are daunting.
> each and every contributor making it his/her personal mission as if it was their Klingon honor
> Id love to see Modula-<n>, or Rust, or anything else used. But the logistics of that are daunting.
I'm curious to know why you apparently think the logistics of the first are feasible but the logistics of the latter daunting. To me there's a clear winner in logistical feasibility, and it's definitely not what you're suggesting.
I may be completely wrong, but the mental picture I have is all thse Linux distros and Windows installs in the whole world, and switching them over to OpenRustSSL from OpenSSL.
I'll stick with the Klingon honor thing - which is fully intended to be utterly hyperbolic. That's just what you can do personally - really polish that thing before it escapes. I know it's painful. But you have to tell your ego to sit that one out.
Well, at least Microsoft is doing their little bit by making C++ and .NET Native the way to go forward in the UWP world, with driver verification tools derived from theorem provers (Z3).
Apple by pushing Swift down developer throats that wish to target their platform (last year only Objective-C specific talks had Objective-C code on their slides).
Google, by making the Android NDK so anemic, that unless one really needs to use it for portable code or that extra performance step missing from ART, no one does it.
But I do concede that this will take a few decades to sort out, even if the IT world suddenly decided to go Ada/Spark/Rust today.
See my comment to parent with Astrobe link. That company put Oberon and IDE into embedded systems. Aside from integration with C libraries, it seems that a combo of rapid compiles, better safety, and better interface checks would lead to less cost in development and easier maintenance. Wait, we already know that with the likes of Go: a modernized Oberon. :)
"We are ALL incompetent at some level, and perhaps on some days."
I lost my memory in an accident. I can relate to the statement. Last time I tried to code something I cheated by defaulting to a subset of FreeBASIC with Cleanroom-style development. It worked the first time it ran. I didn't feel very competent, though, as I saw plenty of room for improvement. :)
""It's not ready. You can force me, but you will first provide documentary evidence of that force ( an email prints off just fine ) and by the way here's what you're risking and do try to keep up.""
Hell yeah! I've got piles of THAT. You can believe it. I try not to even do it coercively. More like telling them it's going to be a problem we can avoid together. It will be a mess if it happens. If forced, I want it in writing so the source of the problem is clear. Otherwise, just let me do it the right was as cost-effective as I can. As usual.
Something like that... can't remember...
"Right now, it looks like we can barely even have a conversation about it."
We can. It's just that the conversation has shifted. It was originally how likely a person could make arbitrary C applications probably sourcing 3rd-party components in haste without severe bugs coming from language weaknesses. That's kind of the default outside some jobs like yours. I was arguing it wasn't going to happen outside super-humans or at least high talent.
This tangent is about what a C programmer with a reasonable scope or chance of high-quality code can do in certain situations to make quality happen. We can have that conversation esp as each embedded person develops on tricks and tooling to eliminate problems. I'd be interested in any resources you have in terms of books, guides, or tools on robust C or embedded systems. I keep lists to pass along to people here and elsewhere that need them along with small chance I might use them.
"Id love to see Modula-<n>, or Rust, or anything else used. But the logistics of that are daunting."
Ada and SPARK already have serious, long-term deployment. Link below that's good even if you don't use them as it shows many problem areas in systems programming along with their solution. Many can be emulated in C with effort. The other is a port of Oberon to embedded systems with ARM Cortex MCU's and Oberon's benefits of course. Be interested in what you think of it at a glance or with hands-on trial to assess if more tools like that should be built. One person even put Ocaml on PIC's. Have fun with these. :)
I am very sorry to hear about your accident. That's terrible.
In your case, I'm sure it's in an advisory capacity/collegial and not an "or else." Just saying - don't ship until youre sure. The cost-gods favor it.
I should probably think about compiling a set of book-style resources to recommend. Seems a bit pretientious, though.
I do think the embedded community should embrace better tools. But I dunno. This will be difficult - sort of a "science only improves one funeral at a time" thing...
> I do think the embedded community should embrace better tools. But I dunno. This will be difficult - sort of a "science only improves one funeral at a time" thing...
To add to the list from nicksecurity, there are other vendors that keep Basic and Pascal compilers alive all the way down to PICs.
"I am very sorry to hear about your accident. That's terrible."
Appreciate it. Totally sucks. Oh well. I'm at least helpful here and elsewhere if not fully operational in INFOSEC market. Working in that direction.
"I should probably think about compiling a set of book-style resources to recommend. Seems a bit pretientious, though."
Ganssle's Embedded Muse has been my main source. He's published a few of my recommendations like I/O coprocessors (or MCU cores) to aid real-time by soaking up interrupts. A few others suggested some books I got. One person made a nice list of blog posts covering various entries. It's really scattered.
So, I wouldn't say pretentious if you were merely sharing resources that helped you in case they help others. Along with what specifically was helpful about each one.
They're not incompetent, they're just developing a web browser. Which means using all kinds of gnarly bleeding-edge optimization techniques that introduce massive complexity just to get Twitter to display 140-byte messages with reasonable performance, not to mention dozens of nasty parsers for nasty data formats. Basically, what I'm saying is that the web sucks. I think web browsers are probably more complex than operating systems at this point.
I totally agree. That's the kind of complexity and BS that developers often have to deal with which I'm referring to. Hard to imagine an unsafe by default language not breaking eventually.
Debugging a C++ template crash is difficult. Finding out why the Windows TCP stack does certain things is difficult. Writing clean and non-memory-over-writey 'C' isn't even close to those.