Certified C compilers for safety-critical embedded systems

The "real world" does not have numbers as well.

... snip ...

I don't think anyone knowledgeable is seriously making such a claim. However, nobody knowledgeable would make the claim that assembly language is unnecessary either, and similarly C is extremely useful as a lingua franca extending over many systems.

As has been pointed out elsethread, it is possible to translate Ada to C, which immediately takes advantage of the de facto portability, but gives up some compile time efficiency and convenience. After all, the usual function of a C compiler is to translate a C program to assembly language, except that that destination is not standardized.

Implementation of run-time checks may require that the C code make extensive use of system subroutines. It may not be possible to use "a = b + c;" statements. At the same time the full C library is probably not needed, and can be heavily pruned for Ada use.

Is that in maths, computing or philosophy?

My phone bill :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

GNP Consumer Satisfaction Index any election year stat women's ages etc etc ...

Of course. Thus the smiley. I freely admit that Ada does checking that no C compiler does. I even admit it may (may!) be a better langauge than C (for appropriate values of "better").

But with the possible exception of the Atmel AVR (GNAT?), there is _no_ Ada compiler for _any_ of the microprocessors I'm using today. For me, that makes C a better language.

No, it's not the same, it's just as close as I could get. But "easy-to-read" is in the eye of the reader. I learned Pascal and Modula-2 years ago, so Ada doesn't look too bad. But other than the variable declaration syntax and some of the strange precedence rules, I find C very easy to read.

Many consider the terseness of C to be a problem or even a disadvantage. But sometimes it helps in comprehension. Consider:

int key; extern int get_key(void); extern void process(int); #define EXIT_KEY 'X'

while ( (key = get_key()) != EXIT_KEY ) process(key);

How do you do that in Ada?

Even the canonical strcpy function is obvious and has a certain beauty. Perhaps you think it looks more like line noise:

char *strcpy(char *dest, char *src) { char *retval = dest;

while (*dest++ = *src++) continue;

return retval; }

But it's "safe" only when used properly.

I wouldn't make that claim. Mine would be that the proper use of a static analysis tool will make C code much better than if you didn't use a static analysis tool at all. Substituting "Ada" for "C" in the previous statement would probably leave it true.

Exceptions are valuable only if handled (think Ariane 5). How would you handle this one?

True. But I don't think even Ada will catch them all. And it certainly does no better than C for e.g. sensor failures.

Regards,

-=Dave

You live in a highly peculiar world. :-)

Martin means array indices, not numbers, IMO.

... snip ...

I won't answer that, but here is how I would do it in Pascal:

FUNCTION nextkey(VAR keyval : char) : boolean;

BEGIN keyval = get_key; nextkey = keyval EXIT_KEY; END;

BEGIN .... WHILE nextkey(key) DO process(key); ....

I have no qualms about factoring out baby subroutines.

Counting in the real world is done in many peculiar ways. For example, at least in the US, house numbers tend to be even on one side of the street and odd on the other.

Counting in computer programs should be done in a way most convenient for the programs to do their work.

with Get_Key, Process;

-- Assuming appropriate declarations elsewhere

procedure Do_it is Key: Character; Exit_Key : constant Character := 'X'; begin loop Key := Get_Key; exit when Key = Exit_Key; Process (Key); end loop; end Do_It;

An extra few lines.

- Ed

Cleanup in Aisle 7.

And it is, generally using binary...

Counting in the _source_ of computer programs should be done in the way to maximize correctness of the computer-human interface. For the number of people who attended a Modern Western Square Dance, that means starting at 8 (any fewer and there was no dance).

And in many buildings, the next higher floor after 12 is 14. In my building, the next higher floor after 14 is PH.

If anything, counting in the real world is a lot like Ada enumeration types.

I'd thought about that, but I remembered my instructors discouraging functions with side effects. I'm not sure why now, other than they'd been teaching us FORTRAN the previous quarter. Certainly after 20 years of programming in C, it seems almost second nature today.

Though one thing bugs me. In C, nextkey would be written something like

int nextkey(int *key_ptr) { *key_ptr = get_key(); return *key_ptr != EXIT_KEY; }

and would be called like

while ( nextkey(&key) ) process(key);

Note the address operator at the call. It makes it obvious (at the point the function is used) that nextkey modifies its parameter (or at least it _could_). In Pascal, the only way to know that is to look at the function definition. In C++, the parameter is likely to be a reference, and have the same problem (IMHO) as Pascal.

Oh, and I never did like Pascal's cutesy way of returning a value from a function... But that's just syntax. Until you try to use the function name as a temporary -- then all recursive heck breaks out.

Nor I. One recent small (PIC) project has 26 function definitions (including main). Since most of these are called from one place (each), the compiler is smart enough to "inline" them so that worst case return stack usage (including interrupt) is 3.

Regards,

-=Dave

Thanks. It was a serious question. I did want to know.

Though structurally, this reminds me of

while (1) /* or for (;;) if you like obscure syntax */ { key = get_key(); if (key == EXIT_KEY) break; process(key); }

which tends to be discouraged.

Another question: Note that in C, even though get_key takes no parameters, it is called with empty parentheses, while Get_Key in Ada looks (syntactically) like any other variable. ISTR that in Modula-2, a function that takes no paramters could be called either way (with or without empty parentheses). Is this true in Ada? FWIW, I like the empty parens because they signal to the reader that something special is going on.

Regards,

-=Dave

Here you hit the main difference between the Pascal/Modula-2/Ada fraction and the C/C++ fraction.

Those Pascal/Modula-2/Ada fraction belive that computer programs should reseble the real word as much as possible and translating beween real world and computer world should be done by the compiler and the optimizer.

Because once the compiler and optimizer have learned to do that will do it right every time. Unlike humans.

I have a lot more experience in C++ then in Ada jet I make a lot more little mistakes in C++ then in Ada. Most of which are type convertions where there is no type is to be converted.

And of course I use warning level 4 to tell me about unsuitable type convertions but it does not help. Mostly because the 3rd party libraries (incl. the STL) are not compatible with warning level 4.

From my experience 10 to 1 (10 times as many silly little mistakes in C++) is realistic.

And, unlike the normal C/C++ developer, who take these bugs K&R given, I know that an Ada compiler would have told me that I am doing something silly.

With Regards

Martin

???????????????????????????????????

This is a matter of language-specific idioms, I'd say. The exit from the statement list of a loop is the most flexible Ada iteration form, but it isn't used all that often - the other forms are more common since they cover most cases.

The empty parens are not allowed in Ada. Bob Eachus or someone else might be able to give some of the rationale. It's a case similar to the choice of () for array indexing rather than []. In Ada, a function result is considered conceptually similar to a constant, as are enumeration literals, and many of the same rules apply to them and their use. I suspect the syntax is intended to reinforce this.

- Ed

In comp.lang.ada Dave Hansen wrote: : while ( nextkey(&key) ) process(key); : : Note the address operator at the call. It makes it obvious (at the : point the function is used) that nextkey modifies its parameter (or at : least it _could_). In Pascal, the only way to know that is to look at : the function definition. In C++, the parameter is likely to be a : reference, and have the same problem (IMHO) as Pascal.

Ada solution that addresses both & and the while(1) issue:

procedure p is

function next_key (key_filled: access Character) return Boolean is separate;

procedure process (the_key: in out Character) is separate;

key: aliased Character;

begin

while next_key (key'access) loop process(key);

end loop;

end p;

-- Georg

Depends on your programming style (and the type of programs you write) how often it occurs. I always use it for "n and a half" type loops, and for tasks where the main body is a loop that is only exited in special circumstances. Certainly in Ada, such loop are not discouraged, although some people get bent out of shape if you have two exits in a loop. I certainly am not going to get upset, or even be mildly concerned about:

loop Input := Next_Char; exit when Input = 'X'; exit when Input = 'x'; Process_Input; end loop;

vs.

loop Input := Next_Char; exit when Input = 'X' or else Input = 'x'; Process_Input; end loop;

In fact I slightly prefer the first form.

There was a time when the parenthesis were required. I think it made it from Preliminary Ada into Ada 80, but definitely was gone before Ada 82. The argument against the empty parentheses was mostly stylistic, but the equivalence of enumeration and other literals to function calls was the real killer. A rule that determine when the empty parentheses were required was considered to be a burden on users, but it also would have been a burden on implementors and the ARG. ;-)

Incidently there are a few cases in Ada where a function result is equivalent to a variable not a constant. Read about return by reference for more details. And of course you can have cases where a function returns an access value, and can appear in a name on the left hand side of an assignment statement:

function Predecessor(Node: Item_Access) return Item_Access; ... Temp, New_Node: Item_Access; ... New_Node.Next := Temp; Predecessor(Temp).Next := New_Node;

Of course, this is a much more common use of functions in variable names than return by reference functions.