Commercial product source code

[MasterBuilder]

Is there any complete source code for commercial products publicly available?

Preferably in C, using GCC with AVR ucontroller.

Im interested in this purely from an educational point of view. I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.

[Rerouter]

The issue you will face there is the more parts in the program the more likely you are to find errors, still if there is a place packed full of example code i could use the learning experience as well,

[Mechatrommer]

not preferably but the one i know "commercialled" in millions https://source.android.com/

[miceuz]

I've seen some commercial production code and I must say, it's a sad story usually...

opensource != bad code
commercial != good code

want to see a good clean code and architecture? check out springframework or hibernate - those in my opinion are rare jewels.

Otherwise it's hellishly HARD to produce good quality code for any substantially large product.

[Richard Crowley]

opensource != bad code

Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?

[MasterBuilder]

not preferably but the one i know "commercialled" in millions https://source.android.com/

Im more interested in source code for control of machines, and  the bigger and more dangerous machines the better.
For example, automotive ECU, ABS/ stability control, other vehicle control sytems, MIRSA compliant stuff, or other stuff like washing machine

Not to say opensource is bad in any way but commercial software Id expect is validated and peer reviewed which is the attraction for me.

[amyk]

Probably very difficult to find some as it's almost certainly going to be proprietary and confidential.

(That being said, some of that stuff does get leaked, and you may find it on some sites in China, but then it also tends to be for Chinese products...)

[Mechatrommer]

Im more interested in source code for control of machines, and  the bigger and more dangerous machines the better.
For example, automotive ECU, ABS/ stability control, other vehicle control sytems, MIRSA compliant stuff

oh now you say it. good luck finding OSHW in safety critical area involving lifes, my best bet will be in IEEE or whatnot, thats not open and thats not free. but they are the domain that you have mentioned. even if i have to make my own safety, expertise alone is not enough, i need to be so intimate with everything, the code, the design mechanical or electrical everything down to the last screw. they are all customly and specifically tied together. the idea of grabbing other people's work (OSHW) that we are not so "intimately" understand and not so specifically tied to our specific need is bothersome imho. i dont know anyone that are so intimate with other's people work at some (high) threshold of complexity do you? by "intimate" i mean, when there is a bug report from someone, just by "imagining" it you'll know the spot where to fix in your thousands of code lines without having to go through retracing or debug process. and hoping this mission critical code works with any systems in the world at the first compile is even more delusional imho. the one that works with everythings are elementary books back in the college. no offense

[madires]

opensource != bad code

Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?

Trolling? ;-) If openSSL would be closed source following would happen:
- vendor ignores report about security issue for some weeks
- after the media picks up the story vendor starts investigating the issue
- if the vendor is in a bad mood he'll sue the security expert who reported the issue with computer fraud
- some 6+ months later the vendor releases a patch

Especially the point about suing caused a lot of security researchers to sell the exploit or to go for anonymous immediate full disclosure.

Another very interesting question is which of the large tech companies using openSSL to make money are supporting openSSL? I've read that Google is giving US$100k per year and Apple US$0.00 for example.

[madires]

Im more interested in source code for control of machines, and  the bigger and more dangerous machines the better.
For example, automotive ECU, ABS/ stability control, other vehicle control sytems, MIRSA compliant stuff, or other stuff like washing machine

Such code doesn't assume anything, it checks everything. In conjunction with the hardware it will fail safe. That's the theory :-)

Not to say opensource is bad in any way but commercial software Id expect is validated and peer reviewed which is the attraction for me.

The reality offers things like cost reduction and time to market which contradict QS.

[free_electron]

opensource != bad code

Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?

Trolling? ;-) If openSSL would be closed source following would happen:
- vendor ignores report about security issue for some weeks
- after the media picks up the story vendor starts investigating the issue
- if the vendor is in a bad mood he'll sue the security expert who reported the issue with computer fraud
- some 6+ months later the vendor releases a patch

Especially the point about suing caused a lot of security researchers to sell the exploit or to go for anonymous immediate full disclosure.

Another very interesting question is which of the large tech companies using openSSL to make money are supporting openSSL? I've read that Google is giving US$100k per year and Apple US$0.00 for example.

You have somevalid points, but i cant help but wonder about a few things
-the source is available. This bug sat there for two years , and did not get fixed until the big stink afew weeks ago

So far for the 'open source is safer because anyone can look over it'... Seems the people that supposedly 'look over' code were asleep for two years.

Second, i have read the report about the problem. Turns out this is a stupid memcopy error.
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 ?
 Arrays should have a structure in them telling their size, as opposed to allowing memcopy to take whatever size you feed it.

The runtime for memory operation must do two things : store the real size of the array in the array, flush a newly created array with all zeroes, upon resize flush the released space or claimed space with zeroes.

Cpu's these days are fast enough that this will be unnoticable.
Just initialising and flushing an array would have prevented this bug.
C may be very powerful but it is a friggin nightmare security wise as it does not perform any safety check. Security applications should not be written using that language.

[cyr]

The wast majority of all code is a horrible mess. For FOSS it usually comes down to "That's good enough, it works for me. If a user finds a problem they can fix it and send a patch". For commercial software it's "That's good enough, we need to ship it next week. If a user finds a problem they can submit a bug report (that will be ignored in reverse proportion to how much money they spend)".

What you are looking for is probably "good code" not "commercial code". There is little correlation, and the former is rare indeed.

[miceuz]

This bug sat there for two years , and did not get fixed until the big stink afew weeks ago

So far for the 'open source is safer because anyone can look over it'... Seems the people that supposedly 'look over' code were asleep for two years.

Well, what has happened? Somebody has *finally* looked at the code and the patch was ready in minutes. Yes, it's a shame that no white hat has looked into it for two years, but at least now we all know the hole is patched up.

Now consider all the holes in windows operating system which allow all the botnets of the world to run.

Yes, I agree, having something like memcpy in a hard-core security related library is a bad design in my opinion too.

To not derail the thread, we have to make the distinction - good structured code is not necessarily bug free code and some explosion in spaghetti factory mess does not necessary contain bugs, but bugs are easier to spot and fix in a good structured code.

[Richard Crowley]

Yes, it's a shame that no white hat has looked into it for two years,

Seems the people that supposedly 'look over' code were asleep for two years.

If "everybody" is in charge, then nobody is in charge.

[MasterBuilder]

Cpu's these days are fast enough that this will be unnoticable.
Just initialising and flushing an array would have prevented this bug.
C may be very powerful but it is a friggin nightmare security wise as it does not perform any safety check. Security applications should not be written using that language.

I would like to make the distinction between good code from a security perspective and good code from a safety perspective. What I'm interested in here is code where safety of the operator was taken into consideration during design.


Im sure there is source code from some projects about, due to companies going bankrupt or commercial projects going opensource, stuff like the code from the NASA guidance system that can be found online.

 Does anyone have any good links?

[madires]

You have somevalid points, but i cant help but wonder about a few things
-the source is available. This bug sat there for two years , and did not get fixed until the big stink afew weeks ago

So far for the 'open source is safer because anyone can look over it'... Seems the people that supposedly 'look over' code were asleep for two years.

Who loves to check code written by another person? Not many, I'd guess. There is more motivation when payed well. Another argument is that, open source is screened by the bad guys to find security holes for their benefit. They won't report them to the dev team of course but sooner or later the attacks will be detected or some white hat reports the issue. That means issues are detected earlier than for closed source.

Second, i have read the report about the problem. Turns out this is a stupid memcopy error.
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 ?

The problem started when the programmer forgot the most important rule for internet protocol implementations: always check any input! If someone asks you to send him a known junk of data with a specific size you should check if the given size matches the real size.

Cpu's these days are fast enough that this will be unnoticable.

For the client, yes. But a server runs several thousands of sessions usually. Simply multiply the number of sessions by the overhead and you'll see it matters. Unfortunately security comes with a performance penalty. You can run PHP in apache with modphp or fast-cgi but you don't get fast and secure.

[miguelvp]

heartbleed was discovered by pen testing it, not by looking at the code.

At work we code review our peer's work and we probably take more time reviewing it than it took to code it.

But look at Nasa's peer review and coding standards for guidance, those guys do everything with check lists.

And for publicly available, and not sure how good their code in here is because it might not be maintain solely by nasa engineers:
https://claraty.jpl.nasa.gov/man/software/index.php

[tjaeger]

heartbleed was discovered by pen testing it, not by looking at the code.

At work we code review our peer's work and we probably take more time reviewing it than it took to code it.

Oh, the hilarity.  Someone who is on record displaying an utter lack of understanding of the security implications of memcpy and an unwillingness to learn is lecturing others on how to avoid security issues involving -- get this -- memcpy.

[Jarrod Roberson]

Im interested in this purely from an educational point of view. I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.

Same way, full or errors, they just cost more to produce and you aren't legally allowed to fix them! :-)

[Jeroen3]

Find some released code which was previously under commercial license. Didn't Microsoft release some parts of .NET?
Or buy something, an RTOS or Networking stack for example. Will cost a few thousand dollars, but you'll have full source.

[ve7xen]

What I'm interested in here is code where safety of the operator was taken into consideration during design.

Therac 25?

(Yes this doesn't answer the question, and the source code isn't available AFAIK, but it's an interesting case study).

[amyk]

stuff like the code from the NASA guidance system that can be found online.

http://www.ibiblio.org/apollo/links.html#Software_manuals_and_listings

Apollo guidance computer firmware.

[MasterBuilder]

What I'm interested in here is code where safety of the operator was taken into consideration during design.

Therac 25?

(Yes this doesn't answer the question, and the source code isn't available AFAIK, but it's an interesting case study).

Very interesting

[dannyf]

There us no assurance that commercial code is of high(ER) quality, or open source code of high(ER) quality either.

an easy source of commercial code would be the OEM libraries. Microchip, luminary and ti all have, in my view, mediocre code. St has better but also buggy code.

the heart bleed is an example whereby a model that is advocated for high quality code fell flat on its face.

in general, I tend to trust code produced by people who livelihood is on the line. On the flip side, open source code has the advantage of having people,s hearts on the line.

so generalization is dangerous.

[westfw]

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_firmware

I 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

[miguelvp]

heartbleed was discovered by pen testing it, not by looking at the code.

At work we code review our peer's work and we probably take more time reviewing it than it took to code it.

Oh, the hilarity.  Someone who is on record displaying an utter lack of understanding of the security implications of memcpy and an unwillingness to learn is lecturing others on how to avoid security issues involving -- get this -- memcpy.

Not following you, I never mentioned we even use memcpy, we have custom classes with overflow protection for what is worth. Also we custom make all kinds of analysis tools for our code base. Including a ton of unit tests for all our systems.

And yeah, maybe it's an overstatement about taking longer reviewing code than writing it. But the reviews are in person and line by line from the changelist and always done by peers that know the system.

Edit: having said that, I do use memcpy for my projects at home, if that is what you are referring to. But I know how to use it and on microcontrollers with limited address space I do abuse it as well.

[GiskardReventlov]

Your question makes a lot of sense to me. Learning a language requires seeing (or hearing) it in use and usage examples.  You are asking for software that was/is in a commercial product but the source code is available to the public.  And specifically MCU code. 

I would check:
github
archive.org
avrfreaks

There must be some other good places to check/ask. I wonder about IEEE and other orgs like that. They may be able to provide pointers (pun).
I may do some looking too because I had pretty much the same thought since I recently embarked on MCU programming.

What I'll eventually do and what I always do in a new langauge after "Hello World!" is to come up with something useful and then implement that.  For example when I tried python I wrote an anagram maker and a news aggregator. I learned a lot. 

My problem right now is to come up with an idea.  I am chewing on an idea to make a passive solar room heater.
The MCU will control a small solar power fan that will run based on an algorithm. The fan will move warm air into the room. The heating part is passive and just uses black tubing.

[SL4P]

Examples only will never guide you in ow to make your software safe or secure.

First suggestion - make conditions fail-safe.
Second - write modular code where possible - and berify each module in itself.
Third - get a peer to  break it
Fourth - wait for issues & bugs to appear... they will

[GiskardReventlov]

Examples only will never guide you in ow to make your software safe or secure.

First suggestion - make conditions fail-safe.
Second - write modular code where possible - and berify each module in itself.
Third - get a peer to  break it
Fourth - wait for issues & bugs to appear... they will

Show us the code then! I think you're missing the point. You can't learn english or german by reading about it. Or having someone tell you the rules of the language.

[IanB]

Im interested in this purely from an educational point of view. I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.

The pros write code that's full of errors too. One reason that commercial code is not readily available is that the owners would often be embarrassed for people to look at it.

There's a simple reason for this. If you make physical devices with bad designs it becomes rather visible. They have gaps in the joins, they vibrate, they squeak, they rattle. You can look at them and see the bad quality.

On the other hand, if you make code with bad designs and poor quality, it is harder to see the problems. If you work hard enough, you can make badly designed code appear to work OK, such that few problems are visible. You can test it a lot and patch over most of the bugs and problems that turn up so they are trapped before they surface. So even if the interior is ugly, the surface can look smooth. Much commercial software is like this. (Which is why, for example, the display driver often crashes on my PCs.)

This is the nature of software. It is often not as good as you would like to hope it is.

The best way to write good software is to learn how to engineer good systems. It doesn't really matter whether the systems you engineer are electrical, mechanical, or software. The underlying design principles are the same. Code is just the material you work with, like metal or wood or circuitry. Learn systems engineering and you will write good software.

[miguelvp]

You learn a language by using it, not by hearing it or seeing it.

Same applies to code.

Edit: but since IanB replied in between, yeah, software, hardware, etc... "engineering" faults in the premise that "it's good enough" that doesn't mean we all do that.

[IanB]

You learn a language by using it, not by hearing it or seeing it.

Same applies to code.

Key factors to writing good software, in order of importance:

1. ...
2. ...
3. ...
4. ...
5. ...
6. ...
7. ...
8. ...
9. ...
10. The language you use to code in.

[Richard Crowley]

You learn a language by using it, not by hearing it or seeing it.

People learn by different methods. Making an absolute statement like that discounts a large portion of learners.
I learned several programming languages by studying examples of the code, with the language reference at hand.

[miguelvp]

You learn a language by using it, not by hearing it or seeing it.

Same applies to code.

Key factors to writing good software, in order of importance:

1. ...
2. ...
3. ...
4. ...
5. ...
6. ...
7. ...
8. ...
9. ...
10. The language you use to code in.

True that, I guess, the same applies to spoken languages. But practice and errors (and learning from them)  is key for both.

You learn a language by using it, not by hearing it or seeing it.

People learn by different methods. Making an absolute statement like that discounts a large portion of learners.
I learned several programming languages by studying examples of the code, with the language reference at hand.

Although you are correct on the learning part of being visual, abstract, etc. You only can master them by using them. No teacher or method can give you that.

[hamster_nz]

Not so sure I agree... for most products it is easy to engineer in safety margins in most products - use more steel, exceed minimum requirements, thicker plastic, more decoupling caps, designed in redundancy and resilience. The tolarance on caps is like +/- 30% or so.

In the most part, building software is more like building in tempered glass. One little defect can cause the whole thing to shatter. It is more like math - for the most part it is either correct or not.

[Mechatrommer]

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 ?

you have it for the longest time... VB, Delphi or probably most of other higher level language did this for you. the irony is they are condemned by the "community". if you want my suggestion, i suggest go for VB (the older one) because its the condemned most for its poorest performance, but handle whats your need pretty nicely.

talking about memcpy or alloc or whatever that do not boundary or zero check, its not the security developers fault, they just use features where provided. it should be mr Ritchie's fault. but no, when looking deeper its Intel's fault and then RAM manufacturers fault (for not providing in circuit exception fault or hardware level memory clearing function), looking deeper no, its actually scientists' and professors' fault. if you want to look even deeper down to the ultimatum, sure you can but i wont mention it here (in my post at least). yes, its easy to finger point when we dont intimately understand the purpose of one thing at hand or just take it for granted.

I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.

The pros write code that's full of errors too.

people always asking the wrong wish... they thought "pros" is all about robustness.they forget the root word of it... "profession", nothing got to do with robustness or zero error. you just need to add a little word to it... "experienced" pros, or "good" pros, but then you dont need the "pros" behind. otoh a "good" "pro" is the one that can take the burden of "given the shortest or limited time" to solve a problem, if you are in the business you know how its done, thats why its kept closed sourced, IanB hinted it pretty well, its no difference with how a kid or developer try to fix others people's code, the only difference with the pro is he is assumed to be expert or full of knowledge in brain about the field.

[vvanders]

Im interested in this purely from an educational point of view. I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.

The pros write code that's full of errors too. One reason that commercial code is not readily available is that the owners would often be embarrassed for people to look at it.

...

This is the nature of software. It is often not as good as you would like to hope it is.

The best way to write good software is to learn how to engineer good systems. It doesn't really matter whether the systems you engineer are electrical, mechanical, or software. The underlying design principles are the same. Code is just the material you work with, like metal or wood or circuitry. Learn systems engineering and you will write good software.

I think you're largely over-emphasising the reason commercial code isn't released. It has more to do with competitive advantage and less with how warty it looks. There's even some cases like data oriented design where something might look "messy" to someone who's not familiar with memory access patterns and caches.

[miguelvp]

people always asking the wrong wish... they thought "pros" is all about robustness.they forget the root word of it... "profession", nothing got to do with robustness or zero error. you just need to add a little word to it... "experienced" pros, or "good" pros, but then you dont need the "pros" behind. otoh a "good" "pro" is the one that can take the burden of "given the shortest or limited time" to solve a problem, if you are in the business you know how its done, thats why its kept closed sourced, IanB hinted it pretty well, its no difference with how a kid or developer try to fix others people's code, the only difference with the pro is he is assumed to be expert or full of knowledge in brain about the field.

Don't even know how to respond to this one, other than saying that I'm paid probably 5 times or more than a junior. I guess companies are stupid and pay us lazy old folk more just because 

[westfw]

All other arguments aside, it would probably be *really good* to look at ANY OSSW project of significant size on code.google.com, or github, or any other source code management framework that would allow you to see a history of edits, problem reports, and email discussions, as well as just the current code.
A project will multiple maintainers would be more interesting than a single-maintainer project.

Bug/"Issue" tracking is a skill of its own, and a pretty important one.

[IanB]

I think you're largely over-emphasising the reason commercial code isn't released.

Yes, of course. I didn't say there aren't other more important reasons, I just picked one of the more interesting ones that's not talked about so much.

[miguelvp]

Yeah, that's why there was such a fuss about letting professional athletes compete in the Olympic Games.

Sure I play some ..... and I'm better than ....

You really don't think professional whatever you choose are not better qualified than people developing on their spare time? and not for a living?

But yeah, if it make you happy thinking that way, go for it. You'll be amazed at the low level of competency kids from University come to the workforce, and they do think they know everything, but that's no new.

But yeah, we do hire the bright ones we can find and develop them, their views in life tend to change drastically.

[andersm]

You really don't think professional whatever you choose are not better qualified than people developing on their spare time? and not for a living?

That's a bit of a non-sequitor. There are excellent hobbyist coders, and there are people who program for a living that are absolutely terrible at it (look no further than The Daily WTF for plenty of evidence of the latter).

[miguelvp]

You really don't think professional whatever you choose are not better qualified than people developing on their spare time? and not for a living?

That's a bit of a non-sequitor. There are excellent hobbyist coders, and there are people who program for a living that are absolutely terrible at it (look no further than The Daily WTF for plenty of evidence of the latter).

As there are excellent hobbyist musicians, artists, basketball players, football players, insert here. If they are excellent they wouldn't be hobbyists. Or maybe they don't care but most do.

[tjaeger]

Oh, the hilarity.  Someone who is on record displaying an utter lack of understanding of the security implications of memcpy and an unwillingness to learn is lecturing others on how to avoid security issues involving -- get this -- memcpy.

Not following you, I never mentioned we even use memcpy, we have custom classes with overflow protection for what is worth. Also we custom make all kinds of analysis tools for our code base. Including a ton of unit tests for all our systems.

And yeah, maybe it's an overstatement about taking longer reviewing code than writing it. But the reviews are in person and line by line from the changelist and always done by peers that know the system.

Edit: having said that, I do use memcpy for my projects at home, if that is what you are referring to. But I know how to use it and on microcontrollers with limited address space I do abuse it as well.

You claimed in the other thread that it is fine and dandy use strcpy and memcpy with overlapping memory regions if you have some control over the standard library implementation despite what the C standard has to say about this.  Not only that, but you viciously attacked a code analysis tool that points out that programs that do this exhibit undefined behavior.

[miguelvp]

yeah, but look at what I said.

I did mention that for some projects you really would want that, but not for microcontrollers where space is limited.

Think about it, if you have over 100 people and over 10 years of code base, you don't want to trust anyone. If you have a little project and you have full control then you don't have to stress that much over other people's usage of your code not knowing what it really does.

There are different beasts all together.

At home and on limited space projects I might even do self modifying code. On big projects with over one million lines of code and with many people touching the code everywhere, there is no way I would do that. Experience will let you know when to use certain techniques and when you don't.

So, we professionals know the limits on what to use and when.

What I said about that project you mentioned is that I rather have our team make the policies (and we have many) than some code randomly telling us what to do. We have to do a lot of crap at 60fps, that means 16.666 ms per frame cycle and it can never hitch and always pushing the boundaries of what the hardware can drive, but with reliability and quality assurance on top of all that.

But if I only have 2K of program space on an MCU for some home project, believe me, I'm going to abuse the instruction set because I will make a point to fine tune it to the max. And I always have been an advocate for assembly for MCU programming, C is good for kernels not MCUs

[westfw]

there are people who program for a living that are absolutely terrible at it

Tthere are also "legitimately professional" EEs, designers, professors, scientists, managers, hobbyists who have made good, and so on, who THINK they can program.  Expert Coders who don't know much about algorithms, expert theoreticians who don't know much about coding.   And lots and lots of people who understand a lot less about "security" (or safety) than they think they do.  All you have to do is go look at the initial sets of RFCs that created the internet, to come up with all sorts of fundamental flaws (mail transfer protocols with no authentication at all, eh?  What a great idea!  Loose source routing?!)  Getting paid doesn't automatically make you an expert, and it especially doesn't make you an expert in ALL of bits and pieces that actually go in to making a product.

[tjaeger]

Think about it, if you have over 100 people and over 10 years of code base, you don't want to trust anyone. If you have a little project and you have full control then you don't have to stress that much over other people's usage of your code not knowing what it really does.

You never have full control unless you know exactly what your compiler does.

There are different beasts all together.

At home and on limited space projects I might even do self modifying code. On big projects with over one million lines of code and with many people touching the code everywhere, there is no way I would do that. Experience will let you know when to use certain techniques and when you don't.

So, we professionals know the limits on what to use and when.

No, you clearly don't.  Undefined behavior is never okay. Never ever. Ever... Ever.

And experience is worthless here.  As compilers are getting better, they optimize more aggressively and all of a sudden code that used to work fine doesn't work anymore or turns into a gaping security hole.

[miguelvp]

Think about it, if you have over 100 people and over 10 years of code base, you don't want to trust anyone. If you have a little project and you have full control then you don't have to stress that much over other people's usage of your code not knowing what it really does.

You never have full control unless you know exactly what your compiler does.

There are different beasts all together.

At home and on limited space projects I might even do self modifying code. On big projects with over one million lines of code and with many people touching the code everywhere, there is no way I would do that. Experience will let you know when to use certain techniques and when you don't.

So, we professionals know the limits on what to use and when.

No, you clearly don't.  Undefined behavior is never okay. Never ever. Ever... Ever.

And experience is worthless here.  As compilers are getting better, they optimize more aggressively and all of a sudden code that used to work fine doesn't work anymore or turns into a gaping security hole.

Bah, you play your safe game with mediocre performing code and I'll keep on playing my top game. And for what is worth, I didn't have to contribute a patch for the last 10 years (knock on wood) and yeah one day I had all kinds of managers around me because of some third party problem but I had a fix for that (without a patch) and never became an issue and when the third party fixed the problem we reactivated the code. But yeah never think outside the box and you'll be safe, but going nowhere.

[tjaeger]

No, you clearly don't.  Undefined behavior is never okay. Never ever. Ever... Ever.

And experience is worthless here.  As compilers are getting better, they optimize more aggressively and all of a sudden code that used to work fine doesn't work anymore or turns into a gaping security hole.

Bah, you play your safe game with mediocre performing code and I'll keep on playing my top game. And for what is worth, I didn't have to contribute a patch for the last 10 years (knock on wood) and yeah one day I had all kinds of managers around me because of some third party problem but I had a fix for that (without a patch) and never became an issue and when the third party fixed the problem we reactivated the code. But yeah never think outside the box and you'll be safe, but going nowhere.

This is getting absurd.  Are you really saying that you need to rely on undefined behavior to get good performance in C?  It's really not that hard:  Undefined behavior means the compiler can do whatever it wants -- which can have disastrous consequences.

[miguelvp]

No, what I said is that compilers shouldn't care about libraries that are not part of the actual programming language as per the thread you are talking about. I can make my own strcpy and I don't want the compiler to police me. So big NO to kcc.

Also what I said also is that if I know the instruction set of the targeted processor, and it can do overlapping memory copies with expected behavior and I would take advantage of that on small MCU.

Also what I said is that I rather program in Assembly because C does a poor job on MCU's.

On large projects tailored to big systems and with a lot of people collaborating, I'll go to safer standards.

I also said that C belongs to kernels, but I wouldn't do overlapping functions there.

If I know that for a particular MCU the memcpy listing behaves like I want it to behave then I might use the memcpy function, but most likely I would use assembly and if I have to support other micros then I will use macros. But only when a program doesn't fit the chip.

There are many aspects to programming. For example displaying a hex number from a 4 line input. I approached it with boolean logic using CPLD like features in a chip, someone else mentioned using an LUT. But using my method I could use the same chip to drive three 7 segment displays, using the "simpler" LUT approach only allowed for two 7 segment displays. So I saved one 3rd of the cost with my more complicated approach.

There are fewer and fewer kids out of University that  know assembly, "Because you don't need it anymore", compilers are crap on what they do and waste a bunch of resources, normally nobody cares because we just throw more resources to it, but on MCU's you just can't do that.

More than your concern with C or C++ or standards I would be more worried about the lack of programmers to embrace functional programming. Multicore everywhere and no program can take advantage of the latest hardware advances. Learn at least some Erlang. I might do you some good.

Cloud computing same thing. C is old, so it's C++ and the funny thing is that Erlang is as old but way different. F# go for it, even Smaltalk, Haskell fine, whatever. C as it is is going to loose it's ground soon because the code will be inefficient in the current hardware.

The thing is, that I do keep up with current trends in both software and hardware, so your thought on what I can do or I can't do are pretty much irrelevant. I will keep on doing what I'm doing because I know myself better than you do, and I know where things are going as well.

One thing is for sure, in programming you just can't stop learning or you'll loose your edge, but the same is true everywhere.

[westfw]

compilers shouldn't care about libraries that are not part of the actual programming language

I'll have to admit a certain sinking feeling when compilers started checking argument types for printf() (and we had our own printf, where %e output an ethernet address, and etc.)  I always figured that C owed a fair portion of its success to the fact that the libraries were NOT part of the language definition, especially when you look at how much of prior languages effort DID go into defining various IO primitives (and not-so-primitives.)  That gave C an agility and portability that the bigger languages just didn't have.

But I think it's a lost battle :-(  And I won't be implementing an "zippy" functions that have the same names as nearly-identical standard C functions.

[dannyf]

compilers are crap on what they do

You would have come cross as a credible participant if you don't make crazy arguments, like the one above.

If that's really what you think, it would be difficult for anyone, including yourself, to have a rationale conversation with you.

[grumpydoc]

No, what I said is that compilers shouldn't care about libraries that are not part of the actual programming language as per the thread you are talking about. I can make my own strcpy and I don't want the compiler to police me. So big NO to kcc.

Also what I said also is that if I know the instruction set of the targeted processor, and it can do overlapping memory copies with expected behavior and I would take advantage of that on small MCU.

Also what I said is that I rather program in Assembly because C does a poor job on MCU's.

While I don't disagree with writing your own routine where which behaves in a particular way which the standard library routine doesn't guarantee please don't call it strcpy - call it my_strcpy or lthmntbmov (low to high memory nul terminated block move) or anything except strcpy.

Calling it strcpy just asks for some bright spark in the future to not understand why you've got a custom strcpy and remove it - giving a 50% chance things will go pear shaped.

It's especially embarassing when you're the bright spark that does the removal. Been there, seen it happen

[Rufus]

Cpu's these days are fast enough that this will be unnoticable.

Open SSL runs on tens of millions of computers processing probably trillions of requests per second. Using a language which automatically checks for things which can't possibly happen in 95% of cases for such software will require extra power stations to be built which is noticeable.

The problem was not a stupid memcpy error it was failure to validate information in a request before processing it. 

[miguelvp]

compilers are crap on what they do

You would have come cross as a credible participant if you don't make crazy arguments, like the one above.

If that's really what you think, it would be difficult for anyone, including yourself, to have a rationale conversation with you.

I stand corrected, let me say it a different way, gcc produces crap code:

Looking at the results for the two compilers we see that GCC has not learned anything over the last five years (this is for how long we have been comparing compilers in terms of OpenMP barrier overhead): The barrier takes roughly a factor of 20 longer with gcc than with the Intel compiler.

http://blogs.fau.de/hager/archives/6883

Don't get me wrong, there are good compilers out there but they are still increasing efficiency by 10% each year, and that tells me they have not plateau yet.

Now throw in 8 cores dual processors, you tell me what compiler uses it all?
None, you might get lucky and scrape 5% of what the CPU can do.

"The way the processor industry is going, is to add more and more cores, but nobody knows how to program those things. I mean, two, yeah; four, not really; eight, forget it." Steve Jobs, Apple.

Then again, he is not a programmer and didn't know anything about computers.

[tjaeger]

No, what I said is that compilers shouldn't care about libraries that are not part of the actual programming language as per the thread you are talking about. I can make my own strcpy and I don't want the compiler to police me. So big NO to kcc.

And "big NO" to gcc and clang, which will both be happy to "inline" standard library function where the only guarantees are the ones given in the C standard (which you should really have a look at), as explained ad nauseam in the other thread.  What I don't understand is, if you're such a genius, how come you've never thought of the obvious solution to this: just define your own function and don't call it strcpy.  I promise that the compiler won't touch it.

If I know that for a particular MCU the memcpy listing behaves like I want it to behave then I might use the memcpy function, but most likely I would use assembly and if I have to support other micros then I will use macros. But only when a program doesn't fit the chip.

Don't use memcpy with overlapping memory areas: It's undefined (== bad).  You can certainly hand-code a memory copy routine in assembler if that's your thing, but it sounds like a waste of time in all but the most limited circumstances.  Use memmove instead.  It does exactly what you want.

[dannyf]

you tell me what compiler uses it all?

You may consider a few things:

1) why do you need to use it all?
2) why should a compiler use it all?
3) what makes a compiler use it all?

[Wilksey]

Referring to the original question,a lot of smaller "commercial" projects are born from other peoples hobby projects, just added protection circuitry and perhaps better rated components and the change to SMT.

The code, well, they will very rarely release this as source files as it would have taken someone time to write, and time is money, I have seen a couple which have been open sourced after years of selling, but the older the product the safer they can release it due to technological advances, i.e. you wouldn't use the same part from 10 years ago today if it was for example, a GSM module, as better, more power efficient chipsets are now available.

If you are interested in a particular industry, your best bet is to get a job working in that sector in a position that you can perhaps have a peek at the code in the repository, you would have to be very careful if you started producing products of similar nature though!

[dannyf]

From a programming logic perspective, you wouldn't see much difference between commercial software and open source - if anything, commercial software tends to lag behind, for reasons like legacy, life cycle management, reliability / liability and / or bureaucracy - I am sure the list goes on.

The biggest differences between the two lie in two or three categories:

1) general architecture: many pieces of hobbyist software are written to perform a specific task, with little thought of what has been done before it and what will be done after it. So they look like hacks rather than modules that can fit into a bigger piece.

I can give you a highly simplistic example. Writing to a spi transmission is quite simple on most mcus: you simply load your data into a transmission register or a buffer and the spi hardware does its magic. That's how most hobbyist spi routines are done: line after line of loading data into the spi registers.

You will rarely see that in a commercial software. What you are likely see are generic functional calls to a spi transmission routine that does some parametric check and then load up the transmission register. At first glance, this may look high inefficient and even redundant. But in a corporate environment, it is far more efficient and / or reliable: the actual spi transmission routines likely come from a proven library that has passed QC; it will be maintained on different mcus that the library supports; .... Once you load the spi library, you know with high degree of confidence that it will work; and if it doesn't, you know precisely where to fix the issues.

Approaches like that allow for fast debugging, low development cost and fast development cycles.

So something that looks highly inefficient / redundant may actually turn out to be highly efficient.

2) documentation: most decent shops do a good job insisting on documentation so the next person handling your code knows how you did it and why you did what you did. and if additional features are to be added, how it can be done efficient.

3) incrementalism vs. grand vision: hobbyist projects tend to start with a grand goal that is too big for anyone person, let alone an underskilled person, to tackle. Commercial projects tend to start small: with a limited set of features and functionality and frequent reuse of early modules / code base. and additional features are built on to it gradually. The emphasis on code modularity and reusing of older pieces is generally not present in a hobbyist project.

4) utilitarian vs. fancy code: you will notice that many hobbyists spend hours trying to make their code go faster, often at the cost of readability, or reliability. Coding in assembly in obscure fashions for example is proudly proclaimed as the status symbol. Those guys are either experts coding for NASA or DoD, or they have never taken on a project slightly more complicated than blinking one led.

As my driving coach told me, the difference between a pro-driver and a street racer is that the pro driver knows when to drive slow in order to drive fast.

[dannyf]

As to code quality: I would say that 99.99% of the hobbyist code is fairly bad. But since the volume of it released is gigantic, you can indeed find gems from time to time.

Quality of open source software is hard to assess, since it is more often than not written by people with varying degree of competence, and as the heartbleed incident shows, with minimum QC too. But you are dealing with people who love what they do, so passion can indeed win out from time to time.

Commercial software in my view tends to be unexceptional but predictably so - I think it is by design (risk aversion) and due to QC.

So if you value cutting edge, go with open source or even a good hobbyist piece (good luck finding it);

if you value reliability (getting the job done), go with commercial software.

If you value getting the job done right, write your own.

[Dielectric]

Wow, derail...

Micrium's uC/OS-II RTOS is some very nice commercial code.  People that I respect hold it up as an example.

http://micrium.com/certification/unequaled-code-quality/
(grab their coding standards doc, good reading)

You can download the source after registering:
http://micrium.com/downloadcenter/micrium-source-code/

There are even a couple of textbooks to go with it.

[dannyf]

Yeah. For learning, those older books on ucos are really nice.

Unfortunately, most hobbyists approach coding from a "writing" perspective, not from a (software) engineering perspective.

[GiskardReventlov]

Wow, derail...

Ha!  It's very common here.

Micrium's uC/OS-II RTOS is some very nice commercial code.  People that I respect hold it up as an example.

Will have to look at this.

Not exactly answering the initial question, but Windows NT source is publicly available.

[Q-Kernel]

Micrium's uC/OS-II RTOS is some very nice commercial code.  People that I respect hold it up as an example.

High quality software requires lots of development effort and time to mature and uC/OS is high quality commercial code.

High quality commercial code is not cheap so there must be a reason for the owner to make it open source. The main reason to make it open source is to get more exposure of the product and sell a version with a different licence model.

We made our RTOS Q-Kernel open source and everybody can use it for free in a non commercial setting like hobby, education, etc. Q-kernel was developed 7 year ago and has matured over the years. We made it zero latency, tick-less, included power management, included publish/subscribe, etc, so we put a lot of money in over the time.

The existing customers financed all this work but hobbyist and the educational world can now use it for free. They have access to commercial quality software including professional documentation which is often missing in non-commercial software.

I think that open source products with a dual licencing model (free license and commercial license) have a great future.

[dannyf]

I mentioned earlier that ST has some bugs in its code base. I was asked if I could mention a few examples. So here goes a short list:

1) HSE_VALUE in device header files.

HSE_VALUE specifies the external crystal / oscillator frequency, and is typically defined in device header files, like stm32fl1xx.h for L1xx devices. It usually takes this form:

Code: [Select]

/**
 * @brief In the following line adjust the value of External High Speed oscillator (HSE)
   used in your application
   
   Tip: To avoid modifying this file each time you need to use different HSE, you
        can define the HSE value in your toolchain compiler preprocessor.
  */ 
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

How retarded a programmer has to be to write code like that?

To their credit, most of those types of defines have been fixed in later releases but it is simply embarrassing to have written something like that.

2) peripheral library 3.6.1 for stm32f10x devices.

The official stdperiph lib is 3.5.0. However, a newer version (3.6.1) is actually available, in stsw-stm32121.

It contains two errors, one of them would have presented their compilation (in _flash.c) - where is ST's QC on that?

Another, in _tim.c, is simply wrong:

Code: [Select]

static void TI4_Config(TIM_TypeDef* TIMx, uint16_t TIM_ICPolarity, uint16_t TIM_ICSelection,
                       uint16_t TIM_ICFilter)
{
...
  {
    /* Select the Polarity and set the CC4E Bit */
    tmpccer &= (uint16_t)~((uint16_t)(TIM_CCER_CC3P | TIM_CCER_CC4NP));
    tmpccer |= (uint16_t)(TIM_ICPolarity | (uint16_t)TIM_CCER_CC4E);
  }

Easy to spot too.

The point? Don't blindly trust anything - open source is fallable, as is commercial software.

[HackedFridgeMagnet]

1) HSE_VALUE in device header files.

HSE_VALUE specifies the external crystal / oscillator frequency, and is typically defined in device header files, like stm32fl1xx.h for L1xx devices. It usually takes this form:

Code: [Select]

/**
 * @brief In the following line adjust the value of External High Speed oscillator (HSE)
   used in your application
   
   Tip: To avoid modifying this file each time you need to use different HSE, you
        can define the HSE value in your toolchain compiler preprocessor.
  */ 
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

How retarded a programmer has to be to write code like that?

To their credit, most of those types of defines have been fixed in later releases but it is simply embarrassing to have written something like that.

Ok, I'll bite. What is retarded about the code?

[Mechatrommer]

1) HSE_VALUE in device header files.

HSE_VALUE specifies the external crystal / oscillator frequency, and is typically defined in device header files, like stm32fl1xx.h for L1xx devices. It usually takes this form:

Code: [Select]

/**
 * @brief In the following line adjust the value of External High Speed oscillator (HSE)
   used in your application
   
   Tip: To avoid modifying this file each time you need to use different HSE, you
        can define the HSE value in your toolchain compiler preprocessor.
  */ 
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

How retarded a programmer has to be to write code like that?

To their credit, most of those types of defines have been fixed in later releases but it is simply embarrassing to have written something like that.

Ok, I'll bite. What is retarded about the code?

since its left unanswered for the week let me shot... imho, for generic library, its wiser non the ritcher to add duplicate or error checking such as an example...

Code: [Select]

#ifndef HSE_VALUE
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/
#else
#error 1234 // just an example or no error raise at all.
#endif


[dannyf]

Or take a look at STM32FCube - particularly where it generates the code.

Totally retarded too.

[madires]

Maybe I'm just anal, but I never let my code go out with any compiler warnings. I know my colleagues don't care so much about some of them, but I feel it's important.

That's a very good coding practice! It also makes it easier to spot the problems if you're not overrun by ton's of compiler warnings.

[Mechatrommer]

which used to compile with hundreds of warnings about potentially unused variables.
...but I never let my code go out with any compiler warnings.

there are some circumtances where we cant avoid warnings, esp higher level or fancier library, though it is agreed excessive use of variables is unwise, and the burden of "variabling" is usually passed to the end developer albeit generic (just like most std c lib). otoh warning flags can be disabled in compiler and at most the penalty is redundant or dormant memory allocation (if the compiler is stupid enough to not bin the unused var). just by looking and practising limited number of libs, if you just know how to make a proper "library" probably you'll quit and prefer to use readymade "proper" lib rather than making your own. just as demostrated, to properly check a single line of definition can take up to 5 lines, mostly managements code. now you want to build a usefull and proper lib? warnings is actually nothing imho. library maker should be from specialized computer science students, not electronics engineers or mcu maker. 2cnts.

[HackedFridgeMagnet]

thanks for the input mechatrommer. Glad to get  a sensible answer to my question.

#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

vs

#if !defined  (HSE_VALUE)
 #define HSE_VALUE            ((uint32_t)8000000) /*!< Value of the External oscillator in Hz */
#endif /* HSE_VALUE */

Still I dont think it is very bad at all. What your crystal runs at the wrong speed if get your include files out of order.
How long before you sort that out. Anyway it's never caught me.

C and the way macros are used in C, provide lots of ways to shoot yourself in the foot and that is not near the worst of them.

Possibly the problem is with C, and the code above is a work around.
Oops ignore that last statement, it may have been a subconscious bit of trolling.

[miguelvp]

Maybe I'm just anal, but I never let my code go out with any compiler warnings. I know my colleagues don't care so much about some of them, but I feel it's important.

That's a very good coding practice! It also makes it easier to spot the problems if you're not overrun by ton's of compiler warnings.

At work we have our projects configured with Treat Warnings as Errors, so nobody can check in code that produces warnings. We have also have a system that notifies everyone who broke the build. Believe me, you don't want to break the build! and that's just part of the whole build project. Just a bad and lazy description on your check-in can cause it to be reverted.

[mrflibble]

Code: [Select]

#ifndef HSE_VALUE
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/
#else
#error 1234 // just an example or no error raise at all.
#endif


If one must use a #define for some reason, then your version is already a lot safer than that happy go lucky summer intern style #define with a tip no-one will read. It's also a lot more verbose, but that's the price you pay... And I would rather have a big fat error and my code refusing to compile, than the mcu silently being configured at the wrong frequency. Or using the wrong frequency value to calculate for example some ADC/DAC settings. (Been there, done that, didn't like it).

What I don't get (except for the economic expedience of using summer interns to produce all that crazy code customers seem to expect) is why they don't use some const expressions for that.

Code: [Select]

static const uint32_t HSE_VALUE = 8000000;

Unless I'm missing something, that should take care of business. No need to explicitely do an #ifdef to check if you are accidentally overwriting a previous definition. Because unlike the preprocessor case, the compiler will whine loudly if you try to redeclare that const variable.

For ueber old code from an era where compiler optimization was maybe not super-duper, okay. But for libraries written in this century I'd think that maybe using const expressions would be better. Better in the sense that it is safer, and it optimizes exactly as well as the #define case.

[AG6QR]

Maybe I'm just anal, but I never let my code go out with any compiler warnings.

That's a very good practice.

However, I've seen code where warnings are taken somewhat casually, and it's not always quite as stupid as you might first think.  I've worked on massive software projects, and some of the source files have lived for over 20 years, and been compiled on 15 or more different compilers over time.  Compiler warnings vary widely from one compiler to another.  Granted, as you weed out warnings for the first five or six compilers, the next few compilers are less likely to find a huge number of new issues, though if the code is voluminous enough, even one new warning type may have so many thousands of occurrences that it's expensive to weed them all out every time you port to a new compiler.  Often it's worth doing, but sometimes it doesn't quite make the top of the priority list. 

I've worked in groups that, after a port to a new compiler, had a policy of, "Every time you change a source code file, clean up all the warnings in it, but don't necessarily go out of your way to fix warnings in old working code where there's no other reason to touch the file".

(For the sake of context, I've worked mainly on commercial software intended to run in big general purpose computers -- mainframes and modern desktop computers -- but I haven't worked professionally on hardware or firmware.  As software scales, the issues change.)

[Rigby]

blah blah.  code is hard to get right.

lots of talk here about lots of stuff, and commercial source code is hard to obtain for one of the exact same reasons (at least) that open source is promoted by lots of folks: all bugs are shallow and obvious if enough people look at it.

no company wants their goofy little mistake to go public.  just look at what people do to each other on forums like this one over unimportant minutia - they eviscerate each other.  there are also legitimate legal reasons that closed source software is closed beyond just the nebulous "it could be embarrassing" reason.

C devs need to run their code through some static analysis tools (which are very easy to procure for businesses, and hard to procure for open source stuff because those tools are so expensive) which would have pointed out this bug many, many years ago.  It's hard enough to convince a C developer that even using an IDE is a good idea, so forget an analysis tool.  "I don't need that crap; I need [vi/vim/emacs/whatever tool one could mention that makes the speaker seem most hardcore].  It isn't done because developers don't trust tools they don't write or that aren't trusted by the community, developers don't want their code to make them look or feel stupid over a silly memcpy bug, and developers don't like it when a computer shows them a mistake that they could not have found on their own.  C devs often like C because it isn't easy, it doesn't always you all errors or warnings, only the few that are mostly obvious and then "damn i musta been drunk when I wrote that."  C programming culture is its own worst enemy.

static code analysis tools have been around a long time, and would have easily found the openssl bug.

closed source is closed usually because it needs to be.

closed source is not inherently better or worse than open source.

[mrflibble]

C programming culture is its own worst enemy.

Humanity is it's own worst enemy, so that C programming culture fits right in.

static code analysis tools have been around a long time, and would have easily found the openssl bug.

On the subject of heartbleed & static code analysis, that's actually kinda interesting. As in, check out the offending version of openssl and run a bunch of default configured static analysis tools on it. Would be a bit sad if indeed that specific bug is pinpointed that way.

And regarding static code analysis, what do you guys use for that for embedded C/C++? Or non-embedded for that matter.
I have "add cppcheck" on the todo list, since it looks to have both standalone and eclipse integration.

[HackedFridgeMagnet]

Code: [Select]

#ifndef HSE_VALUE
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/
#else
#error 1234 // just an example or no error raise at all.
#endif


If one must use a #define for some reason, then your version is already a lot safer than that happy go lucky summer intern style #define with a tip no-one will read. It's also a lot more verbose, but that's the price you pay... And I would rather have a big fat error and my code refusing to compile, than the mcu silently being configured at the wrong frequency. Or using the wrong frequency value to calculate for example some ADC/DAC settings. (Been there, done that, didn't like it).

What I don't get (except for the economic expedience of using summer interns to produce all that crazy code customers seem to expect) is why they don't use some const expressions for that.

Code: [Select]

static const uint32_t HSE_VALUE = 8000000;

Unless I'm missing something, that should take care of business. No need to explicitely do an #ifdef to check if you are accidentally overwriting a previous definition. Because unlike the preprocessor case, the compiler will whine loudly if you try to redeclare that const variable.

For ueber old code from an era where compiler optimization was maybe not super-duper, okay. But for libraries written in this century I'd think that maybe using const expressions would be better. Better in the sense that it is safer, and it optimizes exactly as well as the #define case.

I guess for setting constants in library code you have a few possibly conflicting requirements.
    One is a default setting, so that people can start using the library with a minimum of fuss.
    Another is the ability to change the value of that constant at compile time if it suits their purposes.
    Also it should be done in such a way that if the library has a new version then you can easily integrate the new version of the library into your projects without accidentally overwriting changes you have made.

I dont think the static const would help with this last requirement. Though it would obviously prevent redefines.

I think the best way is write the library and keep its #define dependencies (or constants) all in one file, which is kept somehow separately from the main library.
Then the user can keep the bulk of the library untouched and just fiddle with the constants file, a copy of which is added to each project.

IMO this would be better than sprinkling your project code with overwrites of these #defines.

[Rigby]

lots of talk here about lots of stuff, and commercial source code is hard to obtain for one of the exact same reasons (at least) that open source is promoted by lots of folks: all bugs are shallow and obvious if enough people look at it.

Goto Fail and Heartbleed suggest otherwise.

those suggest that eyeballs aren't actually looking, not that looking doesn't help find bugs.

[gmb42]

Coverity, who sell an expensive static code analyzer, do scan open source projects for free.  They have been scanning OpenSSL since 2006.  Unfortunately their analyzer didn't pick up on HeartBleed, see their blog entry here for more info.

[zapta]

Ok, I'll bite. What is retarded about the code?

He he, you felt for it.  That's Danny's MO. He often baits with a cryptic message and waits for a sucker to ask.

;-)

[miguelvp]

Actually not this time, the comment mentions that you can pre-define it on the compiler, but that header will override it anyways.

But for what I can see , that has been fixed on the current source.

[HackedFridgeMagnet]

Ok, I'll bite. What is retarded about the code?

He he, you felt for it.  That's Danny's MO. He often baits with a cryptic message and waits for a sucker to ask.

;-)

Well I knew it was coming, but I was expecting it to be a bigger issue than what it was.

As for Danny's MO, well it is kind of amusing so happy to play along.

[Richard Crowley]

If "everybody" is responsible, then nobody is responsible.

Perhaps for something so critical, the open-source community should conduct formal code-review sessions where several pairs of eyes review and discuss the code, line by line.

[Rigby]

You said that open source proponents cite many people looking at popular software as an advantage. They were incorrect. I suppose you will claim you were merely repeating what you had heard, not endorsing it, but no-one is going to fall for that.

If people look, they will see the bugs.  They just didn't look.  It's yet another failing of open source software.  If something is trusted it doesn't see much attention.

more eyeballs will find bugs faster.  they just didn't think to look in this case.  such is the case in most open source software i suspect.

[IanB]

such is the case in most open source software i suspect

I don't think this is limited to just open source software. If a software house or development team gets a code library to use, whether free or commercial, they don't tend to look closely at the code inside it. They look at the documentation, ask some questions, do a few tests, and then go ahead and use it.

Third party code doesn't tend to get examined in detail until problems surface. As you say, people tend to trust it. Commercial code is no different in this regard from open source code.

[HackedFridgeMagnet]

Sounds like the heartbeat bug got fixed.

No sure how much trouble it caused, but at least the people who found it weren't sued by a large corporation.

I think plenty of other closed source bugs have caused more trouble than this.

[ve7xen]

Perhaps for something so critical, the open-source community should conduct formal code-review sessions where several pairs of eyes review and discuss the code, line by line.

In light of Hearbleed:

http://www.linuxfoundation.org/programs/core-infrastructure-initiative

[miguelvp]

Perhaps for something so critical, the open-source community should conduct formal code-review sessions where several pairs of eyes review and discuss the code, line by line.

In light of Hearbleed:

http://www.linuxfoundation.org/programs/core-infrastructure-initiative

So let's see, in order to fix open source, companies that depend on it will put professionals to make sure things don't go unchecked.

And there you have it, open source commercial code 

Of course Linus Torvalds will have veto power, right?

[dannyf]

open source commercial code 

I never understood people's fascination with "open source" anything: shit, however free and open, is still shit.

[miguelvp]

open source commercial code 

I never understood people's fascination with "open source" anything: shit, however free and open, is still shit.

I'm all for commercial code and it was a tongue in cheek comment. But since you just quoted the middle sentence by itself then I'll clarify by saying that in order to fix the open source, companies are resorting to actually have professionals (as in being paid to do the task) to ensure the quality they need.

No fascination at all on open sore like I tend to call it.

[HackedFridgeMagnet]

http://www.smh.com.au/it-pro/security-it/microsoft-rushes-to-fix-browser-after-attacks-no-fix-for-xp-users-20140428-zr0p1.html

http://www.smh.com.au/it-pro/security-it/australia-us-uk-advise-avoiding-microsoft-internet-explorer-until-bug-fixed-20140428-zr11i.html

Some people may find it relevant. Some people may not.

[miguelvp]

Weird, I did receive an XP security update for Internet Explorer (after end of life) just yesterday:

http://support.microsoft.com/kb/2964358

[madires]

Weird, I did receive an XP security update for Internet Explorer (after end of life) just yesterday:

Bonus update :-) But what's really weird is that you have your XP PC still connected to the internet 

[Mechatrommer]

what's really weird is that you have your XP PC still connected to the internet 

its not weird to maintain a stable and practical OS. its not weird if its not data sensitive or server PC. its not weird when there are 3rd party security softwares supporting it. whats weird is humanity embracing darwinism novelties.

[tjaeger]

whats weird is humanity embracing darwinism novelties.

Wow, I really didn't think it was possible, but we sunk to another low...

[jaxbird]

Haven't read every single post, but I see plenty of assumptions and speculations on how commercial software if produced.

I can say from experience with some of the largest software "manufacturers" in the world, that it's a tightly controlled process, no feature is written unless it's been ordered, tracked and tested.

Everything is contained in a source control system with full history of who did what and when with who allowed it and why. Sure you have Git in open source, but try tell the contributors they need code reviews and approvals before they are allowed to check anything in And Git is like a toy compared to the features in a modern system.

In production every line of code is reviewed by at least two people, usually an initial review of someone on the same level, then a review by a superior/senior/principal before allowed attempting a check in. Expect to be rejected at least 2-3 times before check in. Can be minor or a total rejection caused by wrong approach.

No check in is allowed to break existing code, so if you need to break compatibility, you need to fix everything that is broken by your change as part of the check in.

Coding style needs to be tightly controlled for easy maintainability, so automated tools will take care of that, no check in until you fixed it all.

Security, automated tools will be run against your code to make sure you have no known open vulnerabilities in your code. No check in unless you pass.

Once you finally get your few lines of code changes checked in, the test team will start their work, they will run a series of specifically designed tests against whatever feature you have been working on. Plus all the tests that cannot easily be automated, everything from memory leaks to slow performance. Plus at number of regression tests.

And that is just for the stuff produced by all the code monkeys, the really important stuff needs to go trough multiple design reviews and much more strict control.

Also it's required that all employees pass a test on the latest security vulnerabilities on a yearly basis. No pass. no job. Sorry.

And yeah, 3rd party libraries, not allowed unless full source available, and full source passes the same security standards required for internally produced code. Any exception requires director level management approval.

[Mechatrommer]

largest sofware manufacturer? http://en.wikipedia.org/wiki/List_of_the_largest_software_companies yeah right! scroll few posts behind, we just discussing IE8 bug that didnt "checked in" for 20 years or so. and oh, you expect 3rd party source code? my advice... make your own libraries, the largest company that is.

[jaxbird]

largest sofware manufacturer? http://en.wikipedia.org/wiki/List_of_the_largest_software_companies yeah right! scroll few posts behind, we just discussing IE8 bug that didnt "checked in" for 20 years or so. and oh, you expect 3rd party source code? my advice... make your own libraries, the largest company that is.

Yes, I have both worked and done consulting for companies on that list.

Not trying to pull anyone's leg, just adding some factual information to this thread instead of guesses and assumptions.

[miguelvp]

largest sofware manufacturer? http://en.wikipedia.org/wiki/List_of_the_largest_software_companies yeah right! scroll few posts behind, we just discussing IE8 bug that didnt "checked in" for 20 years or so. and oh, you expect 3rd party source code? my advice... make your own libraries, the largest company that is.

Yes, I have both worked and done consulting for companies on that list.

Not trying to pull anyone's leg, just adding some factual information to this thread instead of guesses and assumptions.

jaxbird is spot on how we do things at work, other than we do just single peer reviews at the beginning of the project.

As we get closer to release, any change no matter how small requires very good reasons to change (director approved) and dual peer reviews. Even changes that might make total sense can be flagged as risky if it touches too many systems and it gets shelved for future projects. The closer we get to release day, the tighter it gets to change anything.

We all specialize on specific parts of the code. The company doesn't care how much to you have to research something to make sure is spot on and discussed with peers, so it's more about quality than quantity of code they look after.

We also require source for third party libraries and we compile the libraries ourselves. Of course they are glad to give us the source since we pay for the privilege.

And I don't or didn't work ever for any of those companies on that list. Even if we fall between Oracle and SAP but not for software only so we are not there.

[jaxbird]

Jaxbird is spot on how we do things at work...

Thanks, yeah, most people don't realize how much work goes into writing a single line of production worthy code.

Easy to think if you know a bit of programming you can easily do 1000s of lines of code a day, but that will change once you need to get every single line of code reviewed.

And knowing everything you write will be included in your yearly review, where the bottom x% gets the pink slip:D

So yeah, production code quality is by definition much higher quality than open source.

[miguelvp]

what's really weird is that you have your XP PC still connected to the internet 

its not weird to maintain a stable and practical OS. its not weird if its not data sensitive or server PC. its not weird when there are 3rd party security softwares supporting it. whats weird is humanity embracing darwinism novelties.

Not to count licensed software that is tied to my motherboard/OS for a piece of software that is no longer supported but I paid a lot for it, so I have to keep this system going (Accusoft's Visiquest) also I have others tied into this system that I could transfer to a different system but I rather stick with this one for the time being.

[Richard Crowley]

I have several computers used for different things (audio editing, video, editing, graphics, circuit/PC design, etc.).
But most of them are NEVER connected to the public internet because I don't need reference to the outside world to do the particular job.
Of course, sometimes application programs are updated, etc. I don't believe in slavishly "updating" software unless it provides some benefit TO ME.
If I need to update something, I will download the code on my internet-connected machine and then "sneaker-net" the USB flash drive over to the protected PC.
I would be VERY wary about connecting an XP system to the public internet since MS discontinued support.

[jaxbird]

I have several computers used for different things (audio editing, video, editing, graphics, circuit/PC design, etc.).
But most of them are NEVER connected to the public internet because I don't need reference to the outside world to do the particular job.
Of course, sometimes application programs are updated, etc. I don't believe in slavishly "updating" software unless it provides some benefit TO ME.
If I need to update something, I will download the code on my internet-connected machine and then "sneaker-net" the USB flash drive over to the protected PC.
I would be VERY wary about connecting an XP system to the public internet since MS discontinued support.

I think you might have mistakenly posted this in the wrong forum. I might be mistaken, but I fail to see any relevance to the subject being discussed.

BTW: MS is still updating XP even they said it would be the end of it. (but no guarantees for how long)

[miguelvp]

I think you might have mistakenly posted this in the wrong forum. I might be mistaken, but I fail to see any relevance to the subject being discussed.

BTW: MS is still updating XP even they said it would be the end of it. (but no guarantees for how long)

He didn't post on the wrong forum, he was replying to me having still XP, well I'm not too worried about the security of my systems.
I do prefer windows 7 by all means, just have a system stuck with XP because of an expensive license for a product that is not supported, so, that will be my XP machine until I don't need that software anymore. I guess since I have a license I could download and install a cracked version but no reason to do so.

[HackedFridgeMagnet]

Thanks, yeah, most people don't realize how much work goes into writing a single line of production worthy code.
Easy to think if you know a bit of programming you can easily do 1000s of lines of code a day, but that will change once you need to get every single line of code reviewed.
And knowing everything you write will be included in your yearly review, where the bottom x% gets the pink slip:D
So yeah, production code quality is by definition much higher quality than open source.

So no, production code quality is not by definition much higher quality than open source.  FTFY.

How can production quality code be better if it is written by people who cant apply logic correctly to an argument?

Your logic assumes a few things that clearly are not correct.
    One is that every production house does things the same formalised way as you.
    Another is that no open source projects do apply quality controls to the same degree as you specified.
    Another is that the quality controls you specified equate to higher quality code.

Maybe I am being pedantic but I am guessing that is the nature of high quality production code. So it should be second nature to you.
I agree that more reviewing and more care helps create better coding but to paint all OSS as lower quality than commercial source code is a crock of shit.

There are probably better ways of measuring code quality,including things such as
what the user thinks of the code.
the complexity of what the codes does.
bug/issues currently open.
new bug/issue rate.
test coverage.
etc etc but you get the picture.


I think these are so much more important than just a code review. In the heartbeat bug the code was actually reviewed and signed off on.
And the vice president signing off, well that would be a joke in some companies.

@Jaxbird. I am not saying that there is anything wrong with your companies methodology just that your argument is flawed.
I am also fairly certain that if you say your company produces top quality code then I am sure it does.
It's just that I have seen such crap come out of big and small companies with all the QA in the world that I don't believe a corporate culture actually produces code as good as the top OSS projects.


And here is the one that gets me.

And yeah, 3rd party libraries, not allowed unless full source available, and full source passes the same security standards required for internally produced code. Any exception requires director level management approval.

We should trust your companies code even though it is almost certainly closed source?
HYPOCRISY writ large.

[miguelvp]

And here is the one that gets me.

And yeah, 3rd party libraries, not allowed unless full source available, and full source passes the same security standards required for internally produced code. Any exception requires director level management approval.

We should trust your companies code even though it is almost certainly closed source?
HYPOCRISY writ large.

Source is always available from 3rd party libraries (at a price that is)

I bet if you want to pay 100 times more for a gadget so you get source (that you are under NDA not to disclose or to compete against the authors) then sure

[miguelvp]

It actually gets even more complicated than that.

Nothing stops me from creating an open source library but being the author I can choose to make the library or a custom version that is heavily gated, available for commercial licensing. The clients that purchased the commercial license are not bound by the open source license at all.

Offering one license, doesn't exclude you from having other licenses available.

[Dinsdale]

So yeah, production code quality is by definition much higher quality than open source.

http://finance.yahoo.com/news/coverity-scan-report-finds-open-130700038.html

[vvanders]

@Jaxbird. I am not saying that there is anything wrong with your companies methodology just that your argument is flawed.
I am also fairly certain that if you say your company produces top quality code then I am sure it does.
It's just that I have seen such crap come out of big and small companies with all the QA in the world that I don't believe a corporate culture actually produces code as good as the top OSS projects.

If you're comparing top open source projects with all the commercial code out there then of course you're going to find large disparities.

Let me ask you this, how many open source QA people do you see out there? Most people enjoy writing code rather than testing it.

I've spent most of my career working between a mix of open and closed source. Generally widely used open source code is decent if not good. However I've used plenty of broken, poorly written open source libraries as well, some of which I've had to gut almost completely to get an sort of meaningful performance or resource management up the the level required for production.

[HackedFridgeMagnet]

Let me ask you this, how many open source QA people do you see out there? Most people enjoy writing code rather than testing it.

Yes I think that is a very strong point in favour of commercial software. Especially in the early release phase.

However I've used plenty of broken, poorly written open source libraries as well, some of which I've had to gut almost completely to get an sort of meaningful performance or resource management up the the level required for production.

Yes I can see what you mean.

If you're comparing top open source projects with all the commercial code out there then of course you're going to find large disparities.

I guess it would be fairer to consider the top open source software with the top commercial software.  Anyone got contenders for each?
I assume neither Altium nor Kicad qualify. 

[Mechatrommer]

how do you compare open source with a closed sourced? its closed right? and do we need to inspect all the irrelevant paperworks as well? and being approved by the people of management (aka the people in power) i believe naturally, for open source it will first came out broken, and then got reviewed and fixed later on by volunteers. its the same process imho except it usually take some while for those volunteers to chime in, not like profit money based hurry up professionals. and i believe these paperworks and beaurocrates in corporation are what makes bugs fixes take some while to be published, this probably be its drawback.

[mrflibble]

how do you compare open source with a closed sourced? its closed right?

Presumably by being given access to said source under an NDA for the purpose of it being scanned.

[Mechatrommer]

scanned what? by eye, by the said mumbo jumbo analysis tool? or by scanner?

[HackedFridgeMagnet]

Sorry wasn't talking about comparing the source. Though it would be nice. As the original poster asked.

Just comparing the software. There are plenty of metrics people can use to do this without seeing the source.
Obviously impossible to be objective but still people have a good idea of what is going on underneath by the way the software performs.

Windows vs Linux.
Firefox vs Chrome, Safari and IE.
IOS vs Android
GCC vs IAR
Apache vs IIS
MySql vs Oracle, SQLServer
Visual Studio, XCode vs Eclipse, Netbeans ...

Anyway its clear to me that neither is winning in all cases, so it must be possible to produce industry leading code under either regime.

[mrflibble]

scanned what? by eye, by the said mumbo jumbo analysis tool? or by scanner?

"For this latest Coverity Scan Report, the company analyzed code from more than 750 open source C/C++ projects as well as an anonymous sample of enterprise projects."

http://www.zdnet.com/coverity-finds-open-source-software-quality-better-than-proprietary-code-7000028514/

That was mainly to answer the "omg it's closed, however shall it be scanned?" question. Simply, by the owner of that code making it available for scanning. Or more likely by spending $$$ for the license and run it locally on that proprietary code. And probably then upload those metrics, under whatever usage agreement I didn't take the time to find out about.

[jaxbird]

Thanks, yeah, most people don't realize how much work goes into writing a single line of production worthy code.
Easy to think if you know a bit of programming you can easily do 1000s of lines of code a day, but that will change once you need to get every single line of code reviewed.
And knowing everything you write will be included in your yearly review, where the bottom x% gets the pink slip:D
So yeah, production code quality is by definition much higher quality than open source.

So no, production code quality is not by definition much higher quality than open source.  FTFY.

How can production quality code be better if it is written by people who cant apply logic correctly to an argument?

Your logic assumes a few things that clearly are not correct.
    One is that every production house does things the same formalised way as you.
    Another is that no open source projects do apply quality controls to the same degree as you specified.
    Another is that the quality controls you specified equate to higher quality code.

Maybe I am being pedantic but I am guessing that is the nature of high quality production code. So it should be second nature to you.
I agree that more reviewing and more care helps create better coding but to paint all OSS as lower quality than commercial source code is a crock of shit.

There are probably better ways of measuring code quality,including things such as
what the user thinks of the code.
the complexity of what the codes does.
bug/issues currently open.
new bug/issue rate.
test coverage.
etc etc but you get the picture.


I think these are so much more important than just a code review. In the heartbeat bug the code was actually reviewed and signed off on.
And the vice president signing off, well that would be a joke in some companies.

@Jaxbird. I am not saying that there is anything wrong with your companies methodology just that your argument is flawed.
I am also fairly certain that if you say your company produces top quality code then I am sure it does.
It's just that I have seen such crap come out of big and small companies with all the QA in the world that I don't believe a corporate culture actually produces code as good as the top OSS projects.


And here is the one that gets me.

And yeah, 3rd party libraries, not allowed unless full source available, and full source passes the same security standards required for internally produced code. Any exception requires director level management approval.

We should trust your companies code even though it is almost certainly closed source?
HYPOCRISY writ large.

My previous post is just a rough description of how the largest software companies in the world deal with quality control. There are many details I have not covered, such as detailed workflows etc (not trying to publish a whitepaper), but trust me, the largest companies do everything within their power to produce the highest quality code possible for a release. And they usually make sure to hire/acquire leading subject area experts in the fields they are working. Both theoretical and practical experts.

Once you get close to a release, things are tightened up even more. A lot of fear of regression bugs making it into the code, usually you have a ship room manned by senior lead developers, architects, general managers, leading subject area experts and sometimes even marketing people. Their job is to triage all incoming requests for features/changes/bug fixes and decide what will be included and what will postponed to next version/patch etc.

Personally, with these very large companies, I've spent time both on the floor doing development, but also leading teams and coaching developers, plus numerous long hour days in ship rooms leading multiple teams of developers.

Sure the very large companies might not have the initial motivation and spirit of a few guys getting together on an open source project. Instead they run things more like a factory, it's important not to rely on too many individuals, so part of the HR teams job is to make sure they always have someone else to take over if a key employee decides to leave. (if you are in a senior/lead whatever position, it's quite normal that you must maintain an updated list of who are most qualified to take over your position) But there is still room for creativity as long as it passes all the reviews.

In my experience, except for the open source stuff done purely by corporations anyway, such as Android, Chrome, many Linux dists etc. you don't generally have this level of quality control in open source projects.

Of course the production quality from smaller companies can be much lower, as it's often driven by a single (or a few) "know it all/my shit doesn't smell" developers who've been key to a product since it was created. This is very typical, and the quality they produce is usually much lower.

[jaxbird]

I think you might have mistakenly posted this in the wrong forum. I might be mistaken, but I fail to see any relevance to the subject being discussed.

BTW: MS is still updating XP even they said it would be the end of it. (but no guarantees for how long)

He didn't post on the wrong forum, he was replying to me having still XP, well I'm not too worried about the security of my systems.
I do prefer windows 7 by all means, just have a system stuck with XP because of an expensive license for a product that is not supported, so, that will be my XP machine until I don't need that software anymore. I guess since I have a license I could download and install a cracked version but no reason to do so.

My bad  apologies..

Fully understand, MS just want to pressure all their enterprise customers still on XP after the Vista failure to switch to Windows 7 or 8.

But I understand lots of legacy (but still used in production) hardware requires XP to function. I guess last resort is just to cut it from any internet connection and keep a backup image of the OS.

If you have access to Technet you can still download all versions of Windows back to the old 16bit v3.1 or something like that

[miguelvp]

Of course the production quality from smaller companies can be much lower, as it's often driven by a single (or a few) "know it all/my shit doesn't smell" developers who've been key to a product since it was created. This is very typical, and the quality they produce is usually much lower.

^this

If they lump those into commercial source then by all means close source is more broken than open source.

Same with large open source projects, if big companies depend on it, they pay their employees to maintain the open source projects, bringing the quality higher than your average open source project.

[hamster_nz]

Code quality has so many dimensions that it is hard to assess without knowing the constraints that the original authors were working under... budget, timeline, speed, maintainability, performance, manpower, changing requirements. SOmetimes a person operating alone can acheive things in a night that would take a large company a year.

However, I think some people have are just able write better code than others...

[Rigby]

Code quality has so many dimensions that it is hard to assess without knowing the constraints that the original authors were working under... budget, timeline, speed, maintainability, performance, manpower, changing requirements. SOmetimes a person operating alone can acheive things in a night that would take a large company a year.

However, I think some people have are just able write better code than others...

Yep.  People fill open source development roles, and people fill commercial development roles.  The code quality depends almost entirely on the skill of the programmer(s) involved and any restrictions placed on them.  software development is the same as anything else in this regard.  Talent counts, and talent is clearly evident in the finished product.  Peer review counts, and can make any really good software into great software.

[discomike]

Sorry for this blatant self promotion but if you're interested in looking at some automotive code I recently started working at a company releasing an open source (GPL) RTOS and Eclipse based IDE that conforms to the AUTOSAR standard (like POSIX for cars, but waaaay overcomplicated).

Check out http://www.arccore.com/developer/ for access to the repos. We collaborate a lot with academia where the open source concept is appreciated, but also offer commercial licensing and that's how we make our money.


jaxbird: How do you get anything done, you must have worked in aerospace? =)

In automotive standardized concepts regarding functional safety (ISO26262) is just beginning to be deployed, and a lot of people claim it's not needed (mostly those who haven't implemented it yet). One insight I can give you is that quality is not something you can bolt on afterwards with more QA or testing, but a mindset that has to transcend the whole development process.

We see the same in PC software with regards to exploits etc, it's really hard to secure a system when you're reusing the font rendering code for NT 3.51 written without any design considerations on security. Even if you review it how can you "prove" that it reaches some quality goal when it hasn't been designed with that goal in mind.

The only way to "prove" it is by creating some process that you say will lead to your quality goal, and then making sure to follow this process. It's not foolproof, but it's at least something, and much better then some code analysis tool (not saying you can't use those as part of the process).

[vvanders]

...
jaxbird: How do you get anything done, you must have worked in aerospace? =)
..

Perhaps but that type of process is pretty standard across the board at the big software shops. Microsoft, Amazon and Google all follow these practices as does quite a few other places that I've worked at.

[miguelvp]

...
jaxbird: How do you get anything done, you must have worked in aerospace? =)
..

Perhaps but that type of process is pretty standard across the board at the big software shops. Microsoft, Amazon and Google all follow these practices as does quite a few other places that I've worked at.

An ex coworker of mine used to work for Aerospace and now works for Nasa. We got lucky to get him in between jobs and he is brilliant in physics. They are way more strict than that.

What jaxbird mentions is not even close to that kind of scrutiny and very standard like vvanders mentions.

[westfw]

The code quality depends almost entirely on the skill of the programmer(s) involved and any restrictions placed on them

that type of process is pretty standard across the board at the big software shops.

"big" software shops have additional problems just based on the size of their code and the number of people that they have contributing.  Their "heavy" processes barely manage to compensate :-(  (no one thinks that Microsoft/etc ends up producing "nearly perfect" code as a result of these processes, right?)

And you'd be surprised how much software comes from places that are NOT "big software shops."

And EVERYONE has trouble finding good QA engineers.  They're a rare breed, unfortunately.  (Although there seem to quite a lot of people who will CLAIM to be QA experts, implement a bunch of things that the developers find distasteful and ineffective while holding up deployment of fixes AND new features (don't forget that a missing feature is a bug, too), eventually resulting in attempts at completely new development models that will magically keep developers content AND improve quality AND reduced time-to-market...  Sigh.  This is HARD STUFF.)

(There was that Ariane 5 failure, which you can more-or-less attribute to various "standard" edicts aimed at IMPROVING SW quality:
1) thou shalt write the code in Ada!
   (ok, so we write fortran-like code in Ada.)
   (except for the exception mechanism.  oops.)
2) thou shalt minimize thy changes!
   (so we'll redefine "int32" to be a 16bit integer, which means MANY fewer lines of code than changing all those "int32" variable definitions to "int16".  So the code doesn't read like what it does; we minimized changes!)
3) Reuse proven code!
   (sure, even if it's inappropriate and in fact not needed any more.)
(Unfortunately, I'm not finding my link to the video that showed/explained some of these errors.  Sigh.))

[chicken]

Long read, but very apropos to this discussion:
http://stilldrinking.org/programming-sucks