Will someone please kill the C language ? Or at least make a runtime lib that does boundary checking so that this kind of crap can never occur ?
Spoken like an EE. I might as well say "why don't op-amps have an error output when their inputs stray out of the legal range!"
OTOH, there's one example of avr source code used in commercial products: avr-libc.
Any other of many published libraries for other processors: Tivaware. Microchip's USB and Ethernet Libraries. C++ STL. Newlib. gcclib.
Arduino is a commercial product. It's core code is all open source.
Several early 3D printers used OSSW in the AVR-based (arduino-like) hardware controllers.
That may be the closest thing to what you're looking for.
http://reprap.org/wiki/Generation_3_firmwareI don't expect any of this to be very impressive. Vendor stacks and libraries have pretty bad reputations. Eventually I realized that this is because they don't have enough cooks. How many SW engineers do you think Microchip has working on their TCP stack? How many engineers at Microsoft or Cisco work on THEIR (proprietary) TCP stacks? Hint: I'd expect several decimal orders of magnitude difference. Single digits for PICs, 1000s for cisco. (now, there better NOT be 1000 engineers actively modifying TCP at the same time, or you have a different set of problems. But if you have enough people total, you'll have a bunch of them like free_electron, frequently complaining how awful things are. Sometimes they'll be wrong. Sometime they'll improve things. Sometimes they'll be listened to, and other people will improve things. And sometimes they'll be ignored even when they're right. Of course, not all commercial code is written by large SW teams, either.)
Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?
Well, I suppose you could define any SW with bugs as "inadequately reviewed", but I'd say that the Heartbleed bug was one of those things easily overlooked in a review (perhaps they concentrated too much out output buffer overflows!) It was the Apple SSL/TLS bug that had "obviously inadequate" review.
Just initialising and flushing an array would have prevented this bug.
That's not the way I interpreted the analysis. The source and destination were not arrays. The destination was properly sized and zeroed. There WAS data in the structure defining the length of the array (but it was provided from external sources, and did not match the actual size.)
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html