7 ms·
F-35 C++ coding standard [pdf]
- foobarqux 13y agoNote that military requirements are typically less stringent than those of commercial aerospace.
- z3phyr 13y agoHow are the requirements less stringent?
- foobarqux 13y agoThere are fewer regulations, many of them informal and they don't answer to the FAA but to some branch of the DoD. This makes sense since military aircraft don't usually transport civilians or operate over populated areas. See the software section of this document which says that military airborne software isn't, in general, acceptable to the FAA, which implies that the military are bound to weaker standards. http://www.faa.gov/documentLibrary/media/Order/ND/8110.101.pdf http://www.faa.gov/documentLibrary/media/Order/ND/8110.101.p...
- john_b 13y agoPrevious sumbmission and comments: https://news.ycombinator.com/item?id=3967316 https://news.ycombinator.com/item?id=3967316
- secstate 13y agoI feel like if I were a pilot with even a modicum of engineering and language experience, I'd be pretty frustrated that they aren't using something like Haskell that provides a certain level of runtime security. C++ seems like it has enough ways to generate a memory leak to sink a boat, or drop a fighter out of the sky.
- vitno 13y agoWhile initially this seems like a good idea, and I thought things like this for a while... I'm sure they are using a real time operating system. Imagine having things garbage collect for you when trying to fire a missile. This may seem inconsequential, but reliability is everything. https://en.wikipedia.org/wiki/Real-time_operating_system https://en.wikipedia.org/wiki/Real-time_operating_system edit: also, time/space leaks in haskell.
- john_b 13y agoC++ may not be the best choice, but a language like Haskell would be worse for an aviation application for a number of reasons: 1) Memory on the hardware is tightly constrained and controlled, and you need some visibility into its usage at any given time. Even if it exposes you to null pointer errors and the like. 2) Along the same lines, throughput must be predictable and is tightly constrained. Anything happening at runtime that can't be predicted at compile time is, for a safety critical aviation application, a huge risk and is usually explicitly forbidden by the requirements. 3) Haskell is relatively new. C++ has stood the test of time and the DoD can be sure plenty of C++ programmers will still be around in 30+ years. All of these are dealbreakers from the DoD's perspective. The technical risks associated with handling your own memory and not having provably safe code can be addressed with enough time and expense. Since the DoD is not short on money and operates on time scales of years or decades, this is acceptable. In a startup or academic environment, the balance of risks and resources is completely different. But believe it or not, the DoD and commercial aviation entities actually do look at the tradeoffs associated with the tools they choose and don't simply choose them out of inertia. Source: I develop commercial jet engine software, where many of the same resource/risk tradeoffs exist.
- ihnorton 13y agoNo disagreement, but wanted to point out that groups like Galois have been using Haskell-embedded, compile-to-C DSLs in some interesting ways recently: http://smaccmpilot.org/images/dronecon-talk.pdf http://smaccmpilot.org/images/dronecon-talk.pdf This has the potential for nice compile-time guarantees without the runtime cost (and potentially at much lower cost than full formal verification) (also, fwiw, Haskell has been around since 1990, making it about 7 years younger than C++)
- dgreensp 13y agoDid the poster have some point in mind, or do we just post random PDF documents on HN now?
- wil421 13y agoI thought the military uses Ada? Edit: Link in case anyone is interested from the discussion below is interested. http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
- vonmoltke 13y agoThe DoD has not used, and has in fact strongly dissuaded the use of, Ada for almost 20 years.
- wil421 13y agoUmmm.... tell that to the people I know who work at lockheed. Edit: did some research and the people I know work on projects started before the change; F-22/C-130. And it wasnt 20 years ago more like 15, although I couldn't find an exact date.
- josephschmoe 13y agoAda is something of a running gag in the aerospace industry at this point. Only really, really old programs still use it.
- kjs3 13y agoMust be really old programmers working on the Boeing 777 flight control system.
- wil421 13y agoSo the "backbone" of a 787 is considered a really, really old program? http://www.adacore.com/customers/787-dreamliner-common-core-system/ http://www.adacore.com/customers/787-dreamliner-common-core-...
- vonmoltke 13y agoIt was 1997 that DoD started their COTS push. I actually worked in some of the Ada code in the F-22. The code and the SBC it ran on were designed in 1993. My understanding is the code was rewritten in C++ in about 2009. I believe the Ada code in the F-22 PICC module went the same direction as the module design evolved.
- amaks 13y agoNo wonder this thing doesn't fly (as expected). In all seriousness, perhaps the choice of the language has affected the software release dates?
- amaks 13y agoI'm surprised folks are down voting my comment. See http://rt.com/usa/f35-jet-software-delay-233/ http://rt.com/usa/f35-jet-software-delay-233/ for example. And as the one who programmed in C++ for 20 years I think I know what I'm talking about.
- w0utert 13y agoYou are being voted down because your comment was completely unsubstantiated. Maybe if you had thought about it a little longer you'd have figured put there aren't actually that many (any?) viable alternatives for C++ for the kind of systems programming you'll find in a fighter jet. Or, if you disagree, you could have offered some insight as to what these languages would be. If you can't have non-deterministic behavior such as GC, you can't waste gobs of heap or stack memory, you have to be able to interface with C libraries and embedded components, you need hard real-time guarantees, and your whole development stack needs to be stable and well supported, you end up with C or C++, it's that easy. You don't gamble by picking the hipster language du jour all the cool kids use to write websites or phone apps, but proven technology that (if used correctly) gives you reliable and predictable results, and will still be around and supported in 40 years time when these jets are still in service. Blaming the failure to deliver the f35 on time and within budget on C++ is really quite a cheap stab.
- Jtsummers 13y agoC/C++ aren't the only languages that lack a GC (see Ada) or in which you can severely restrict the GC (see Rust, though it's not suitable for this sort of project yet). The OS that most of the software runs on (that is, not the software running on LRUs with their own embedded OS) offers the same APIs to Ada and C and C++. It was a choice to go with the non-Ada languages. Ada is hardly a hipster language, it's been around for 35 years and will likely be around the rest of this century (for better or for worse).
- russoue 13y agoI thought the avionics software are written in Java these days.
- AnimalMuppet 13y agoStrongly real-time embedded systems and garbage collection don't play well together.
- russoue 13y agoThanks. I was just joking and it seems like a lot of people did not get it :(. My joke was targeted to the people who think if there is one programming language left in the world it should be Java.
- AnimalMuppet 13y agoAh. I'll adjust my sarcasm detector...
- fbomb 13y agoI stopped reading after the very first rule: Any one function (or method) will contain no more than 200 logical source lines of code. Seriously?
- mercurial 13y agoWhat of it? It's a lot of code, but it's C. Simple things usually take more lines than in higher-level languages.
- fbomb 13y agoNo. Actually it's C++. A very different language.
- mercurial 13y agoTrue enough, but in any case, C++ is still fairly noisy.
- exelius 13y agoC++ is also not Java. When you're working with low-level hardware on real-time systems, C++ ends up looking a lot like C. Besides, most commercial applications of C++ tend to devolve into "C with objects." IMO this is because well-written blocks of C are actually very readable, and you're a lot more likely to mess up memory management when you start passing data around just to break up large code blocks. The whole reason Java has garbage collection and only one way to pass objects is because they help write more readable code.
- TrainedMonkey 13y agoI do not think there is a viable alternative to C++ as a systems language, thus it's utilization in a complex project combining many systems developed by different parties makes sense. That being said, no humanly comprehensible amount of rules can make average engineer churn out good C++ code and no amount of good engineers can save project with bad management.
- steveklabnik 13y agoHave you checked out Rust yet? It's too unstable to be a viable alternative yet, but I have high hopes.
- vowelless 13y agoI don't think Rust is aiming for hard real-time systems. Other than that, I too am quite excited for it.
- Jweb_Guru 13y agoIt is definitely aiming for hard real-time systems. It's not quite there yet, but the Rust developers been hard at work removing obstacles to its use in those situations.
- mercurial 13y agoFrom the little I read about the F-35, the problems started with "bad requirements".
- jasonwatkinspdx 13y agoGalois and others have had success using Haskell, or using Haskell tooling to generate formally assured c/c++. I think there's plenty more industry could be doing today, even when tied to c/c++.
- fzltrp 13y agoYou said viable, so I guess you mean production ready, which excludes still experimental or "in gestation" languages like rust or ATS, but they are indeed worth a look (note that ATS in its 1st incarnation targets C). I'd like to point out that there was a post several weeks ago on /r/haskell of someone having implemented a BSD kernel module. There's also MirageOS, an OCaml implemented framework providing all the services of an OS, thus letting people boot their apps in a VM very easily (that's the aim of the project afaik, given that it comes from the same lab than Xen. While not specifically tuned for OS development, they seem able to cope well with the task. Note that both languages also have a native SSL library development ongoing, which is a part of the MirageOS framework in the case of OCaml.
- tdicola 13y agoDon't get too wrapped up with these standards. When asked about them Stroustrup himself said they aren't a general C++ standard, but something very specific to the embedded & critical systems of fighter jets. I can't remember the exact talk, but it was from one his Going Native talks: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style http://channel9.msdn.com/Events/GoingNative/GoingNative-2012... or http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup http://channel9.msdn.com/Events/GoingNative/2013/Opening-Key... (both are _well_ worth a watch if you like C++ or program in it)
- deleted 13y ago[deleted]
- smutticus 13y ago"4.13.4 Function Invocation AV Rule 119 (MISRA Rule 70) Functions shall not call themselves, either directly or indirectly (i.e. recursion shall not be allowed)." That's too bad.
- barkingcat 13y agoThat's a good rule for embedded software on a jet though. I can see why they'd do that.
- AnimalMuppet 13y agoNot if you want provable worst-case stack sizes (function call times). [Edit: or function call times]
- SoftwareMaven 13y agoUnexpectedly running out of stack space at Mach 1 while pulling a 5g maneuver is a little different than unexpectedly running out of stack space while playing tetris. Most recursion can be rolled into loops, so it's not completely limiting.
- Jtsummers 13y agoThe rationale is sensible though. C/C++ do not have tail call optimization, recursion reduces available stack memory which is a limited resource. By barring recursion, note they also bar malloc after initialization, they allow the program's memory usage to be determined at compile time, rather than during runtime. This allows them to satisfy requirements like "shall not use more than 50% of memory" (NB: this doesn't mean it will never use more than 50%, that extra memory available allows them to modify the program in the future and relax the memory constraint as needed without needing to modify hardware).
- rvkennedy 13y agoI couldn't help but search the pdf for brace rules, and lo: AV Rule 60 Braces ("{}") which enclose a block will be placed in the same column, on separate lines directly before and after the block. Example: if (var_name == true) { } else { }
- exelius 13y agoHey, nothing wrong with that. As long as there's a consistent standard, it does make things more readable.
- rootbear 13y agoI agree about consistency but I don't find that style more readable. It wastes vertical space to little benefit.
- john_b 13y agoI agree with you stylistically and don't personally use that brace placement. However, given the number of people writing C++ code for the F-35, it makes sense to settle on a standard that is never ambiguous. When nesting multiple control statements, it can sometimes require good judgment to know where to place braces for maximum readability. Giving each one its own line avoids requiring your developers to exercise good judgment in all the myriad cases.
- exelius 13y agoYeah, but that's a stylistic choice. IMO this is one of those cases where one choice isn't better than another, and it's just better to have made a decision.
- Too 13y agoI think he's referring to apples "goto fail" bug to show it wouldn't happen under a project with strict guidelines :)
- rootbear 13y agoThey require that pointers be declared as int32* p; and not int32 *p; and I know that is the convention in C++, but it still makes my eyes bleed. It's a gross violation of the Law of Least Astonishment, since, of course, int32* p,q; doesn't do what you might think it would, based on the syntax. This is not a problem for the F-35 code, since multiple declarators per declaration are forbidden. Sorry, I'm an old C guy and I guess there are some new tricks I just can't learn...
- deleted 13y ago[deleted]
- exelius 13y agoIt seems that this standard definitely goes for clarity of code over syntactic shortcuts. Which, you know, is probably a good idea for critical system software on an aircraft. It's better for your intermediate developers to know exactly what your code is going to do than to be able to use some greybeard tricks that can lead to buffer overflows if the person modifying them doesn't know exactly how they work.
- pkolaczk 13y ago"AV Rule 1: Any one function (or method) will contain no more than 200 logical source lines of code" Are they crazy? 200 SLOC is a huge beast. With our non-mission-critical software, we typically aim to not exceed 20 lines of code per function, and this including comments and whitespace. Typically it is not very hard to get functions of size < 10 sloc.
- Jweb_Guru 13y agoWith your non-mission-critical software, you also probably don't have hard limits on recursion. Writing iterative versions of naturally recursive functions can blow up function sizes fast.
- john_b 13y agoI'm not sure if they're defining "logical" lines of code as all non-comment lines, but if so the requirement to have all curly braces ({}) on a line of their own would add to the vertical line count.
- ape4 13y agoMany of these standards are pretty reasonable.
- deleted 13y ago[deleted]