F-35 C++ coding standard [pdf]

[rootbear]

They 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...

[exelius]

It 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.

[tdicola]

Don'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...

or

http://channel9.msdn.com/Events/GoingNative/2013/Opening-Key...

(both are _well_ worth a watch if you like C++ or program in it)

[wil421]

I 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

[Jtsummers]

It's not used 100%. As a mandate it disappeared a while ago, anyone that's using it is using it because of institutional momentum (rare) or some cost/risk analysis, or projects they've inherited or a rare mandate from the program office. I'd be happy if it were used more often, but it's not. And I'm not sure where vonmoltke gets that use is dissuaded, that's not been my experience. It's often that the language chosen isn't mandated and companies just don't choose it (there was too big a backlash in the 80s about the original mandate).

--------------

EDIT

The OS [1] for the F-35 and the 787, tightly integrated with development environments for Ada and C/C++. I really don't get the Ada knocking going on, it's a solid language and a hell of a lot better than C/C++. The reason it loses is corporate culture and lack of familiarity from developers, and an inherited hate/dislike that's persisted since the 80s. For these applications it really is the better language.

[1] http://www.ghs.com/news/archive/211031l.html

[vonmoltke]

The DoD has not used, and has in fact strongly dissuaded the use of, Ada for almost 20 years.

[foobarqux]

Note that military requirements are typically less stringent than those of commercial aerospace.

[z3phyr]

How are the requirements less stringent?

[rvkennedy]

I 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]

Hey, nothing wrong with that. As long as there's a consistent standard, it does make things more readable.

[john_b]

Previous sumbmission and comments:

https://news.ycombinator.com/item?id=3967316

[TrainedMonkey]

I 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.

[fzltrp]

You 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.

[mercurial]

From the little I read about the F-35, the problems started with "bad requirements".

[jasonwatkinspdx]

Galois 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++.

[steveklabnik]

Have you checked out Rust yet? It's too unstable to be a viable alternative yet, but I have high hopes.

[pkolaczk]

"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]

With 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.

[ape4]

Many of these standards are pretty reasonable.

[smutticus]

"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.

[SoftwareMaven]

Unexpectedly 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]

The 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).

[AnimalMuppet]

Not if you want provable worst-case stack sizes (function call times).

[Edit: or function call times]

[barkingcat]

That's a good rule for embedded software on a jet though. I can see why they'd do that.

[secstate]

I 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.

[john_b]

C++ 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.

[vitno]

While 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

edit: also, time/space leaks in haskell.

[vowelless]

Haskell cannot give hard real-time guarantees, to my knowledge. C++ can (if you don't use some features like exception and dynamic_casts [1])

[1] I should point out that dynamic_cast is a little tricky -- http://www.stroustrup.com/fdc_jcse.pdf

[mcmancini]

In addition to the other replies, Haskell lacks a proper ISO or ANSI standard.

I think that current safety-critical best practices (what real software engineers actually do) do a good job at correcting the warts inherent to the C family while respecting the need for real-time execution. Not clear what Haskell brings to the table here (or on other embedded systems in general).

[wtracy]

That's exactly what the DoD created Ada for. Unfortunately, programmers that know Ada seem to be in short supply.

[russoue]

I thought the avionics software are written in Java these days.

[AnimalMuppet]

Strongly real-time embedded systems and garbage collection don't play well together.

[fbomb]

I 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]

What of it? It's a lot of code, but it's C. Simple things usually take more lines than in higher-level languages.

[dgreensp]

Did the poster have some point in mind, or do we just post random PDF documents on HN now?

[amaks]

No wonder this thing doesn't fly (as expected). In all seriousness, perhaps the choice of the language has affected the software release dates?

[amaks]

I'm surprised folks are down voting my comment. See 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.