标签: adacore

In a recent column , Jack Ganssle enthusiastically greets the arrival of Ada 2012 because it incorporates features and capabilities that he has been working hard to convince C and C++ embedded systems programmers to adopt explicitly and after the fact into their programming practices. Even with the new capabilities incorporated into Ada 2012, there remain sceptics in the developer community who do not think Ada will be a factor in the mainstream of embedded programming. Part of that is due to the fact that Ada was developed in the early 1980s as a programming language for safety-critical military and aerospace applications. But the nature of the embedded systems that software developers work on is changing as the devices they develop insert themselves into our daily lives in a way that the desktop computer never did. They are in the power grid that serves our homes, in the meters that monitor our power useage, in virtually every electric appliance and entertainment device, in our light bulbs, in our phones, in our automobiles and in new intelligent medical monitoring devices – and many of them are connected to each other, to each of us and to the broader internet. This new environment is certainly one in which something closer to the requirements for safety-critical design is needed. If not safety-critical, then dependable, absolutely dependable. In some environments, such as in the auto, and in the increasing number of medical monitoring devices we use, this need is an obvious no brainer. In others, the failure of the embedded design may be only an irritating inconvenience for the user. But if such failures happen often enough, those failures may be critical to the continued existence of the company that built them. Also, many of the standards organisations that serve the needs of various industry segments – industrial, consumer, medical, transportation—are adopting software reliability and dependability requirements every bit as demanding as those in safety-critical military/aerospace applications. But if you're still convinced that you do not need anything other than C or C++ in your in your embedded designs, consider the argument of Greg Gicca of Adacore in "Students need to learn multiple programming languages" – that learning about and using another programming language such as Ada might help you think better and write better C/C++ code. If it is true for computer science or electrical engineering majors in college, it is true for professional programmers as well. " Understanding just a single language promotes solutions that only approach a problem from a single perspective ," he writes. " Knowing multiple languages allows the problem to be looked at from a variety of perspectives so that multiple solutions can be compared and the most natural solution for the problem can be selected." One good example of this ability to think about C-code development in a different way is " Seventeen steps to safer C code ," by Thomas Honold, who was faced with the challenge of writing a C-based project with safety and reliability demands that C could not satisfy. His earlier experience with Ada in a number of earlier military/aerospace projects made it possible for him to come up with a set of techniques and procedures for use with C to satisfy the requirements of the project. The issue of the best programming language is a complex one. I would like to hear from you, in response to this article, or in blogs and articles for publication on the site and in the newsletters about your experiences and thoughts about programming in general, on Ada, on C or any other language with which you've had experience.  

In a recent article, Dan Saks noted that Embedded.com surveys over the last dozen years indicate that we primarily use C in embedded applications. C++ is a distant second, with everything else being in the noise. Part of that noise is Ada, a language that dates back thirty years. Once, many developers thought that the language would become dominant, due in part to a DoD mandate that required its use in many of their contracts. Alas, it was not to be. Today Ada is found most often in safety-critical applications. Its Wikipedia entry contains the clause: " Because of Ada's safety-critical support features, it is now used not only for military applications, but also in commercial projects where a software bug can have severe consequences..." "Severe consequence" is much more than airplanes falling out of the sky. Consider the recent Knight debacle. I'm sure the CEO feels a half-billion dollar glitch is a big deal. How about the four million hotel locks – a very simple embedded app—that have a brain-dead security vulnerability? A simple hack with $50 worth of parts can open all of those doors. How many automotive recalls were initiated due to bugs? Then there's that $600 million recall of infusion pumps. And the SCUBA dive computers that gave incorrect – and dangerous – numbers. The list of expensive firmware bugs could fill a book. Even in the most innocuous product that hasn't the faintest tinge of criticality a bug can be expensive or reputation-killing. There is a small community of Ada users who routinely crank out code an order of magnitude less buggy than common in the C/C++ world. The language has been revised several times. The latest is Ada 2012 which is expected to get an ISO approval this year. The new version has some fantastic additions. I'm enthusiastic about the new support for Design by Contract, an Eiffel notion created years ago by Betrand Meyer. Meyer believes the way we write functions is broken. He notes that functions don't exist in isolation; they are part of a huge ecosystem of relationships – functions calling other functions with sometimes wild abandon. Those relationships are as important as the code in the functions, and with DbC we write "contracts" that enforce those associations. It's not a new idea. I remember being taught 40 years ago to check goesintos and goesoutas in FORTRAN subroutines. Eiffel has built-in mechanisms to support writing contracts. C doesn't. Some – too few – developers will use the assert macro to detect errors automatically. Ada 2012, though, now includes contracts as part of the language. So, for example, one can establish a precondition (something which must be true when a routine is entered) or a postcondition (true at exit) that tests, at runtime, a buffer overflow. A number of studies have shown that the widespread use of contracts, or even of assertions in more primitive languages like C, can detect 80% of the bugs in a program, at roughly a tenth the cost of traditional test and debug. Ada 2012 comes with a number of other new features. It does not give up the notion of profiles. While a lot of developers shun Ada for its perceived overhead compared to C, subsets like the Ravenscar profile reduce the required runtime footprint considerably. There's more information available from AdaCore . And they will have a compiler for the new standard quite soon.  

Almost a decade ago a number of static analyzers began to appear in the market. A number of such products exist now, including those from Coverity, PolySpace ( now part of The MathWorks ), Grammatech, Green Hills, Klocwork and others.   Static analyzers examine your code to find runtime bugs. While quite expensive today, most of the developers I know who are using the tools agree that they are effective. Expensive, yes. Sometimes slow. And they hardly find all of the bugs. But they do find some of the tough ones.   C programs are, of course, particularly vulnerable to problems like memory leaks, so it seems the biggest market for these products is in that domain. But even safe " or at least safer " lingos like Ada are not immune to difficult-to-find bugs. AdaCore has teamed with SofCheck to bring the latter's static analyzer into the world of Ada systems. The resulting CodePeer product seems like a worthwhile addition to an Ada programmer's toolbox.   But CodePeer is much more than that.   One of the oldest precepts in programming is to check your goesintas and goesoutas. A square root routine that's grounded in the real domain should toss an exception if one passes a negative number to it. But how many functions check their parameters?   Nearly a quarter century ago Betrand Meyer invented "Design By Contract" which codifies these checks.   In DBC one defines formal contracts that check functions' inputs and outputs. Some languages, like Eiffel, provide built-in support for contracts. In C one uses work-arounds with a preprocessor or tortured assert() statements. Regardless, DBC is a philosophy of the developer manually writing out the contracts.   CodePeer twists this idea in an intriguing way. It examines the code and creates the contracts for you. They get embedded into comments and are not executable, but they provide clear cues to the developer that things may not be as they should. For instance, in the snippet below from AdaCore's web site the postcondition ( labeled "post" ) immediately makes it clear that the function has a glaring bug:     Just imagine how much more effective a code inspection would be given this information!   The tool does much more, but this is an indispensable aid to the Ada developer. Bugs are tough to find and potentially hugely expensive ( think: Toyota ).