Expressive vs. permissive languages: Is that the question?

4/7/2010 11:35 AM EDT

The concept of contracts is definitely interesting, and perhaps something new programmming languages for embedded systems should consider adapting.

Though note that most of the concerns in this article are completely irrelevant to embedded systems. Embedded designers strive to make their products idiot-proof, rather than hacker-proof. So in embedded systems you will typically find the number of attackers == null. The number of Java users are also null. Dynamic allocation is used sparsely. And I'd rather not have my car call the exit(1) function, i.e. "let go of the wheel and cover your eyes with both hands upon error".

For the C example, the article should in all fairness compare apples and apples. The equivalent C snippet to the Ada example would look like this:

/*** types ***/

typedef enum

{

  ALLOC_OUT_OF_MEMORY,

  ALLOC_OK,



} Result_t;





/*** constants ***/

static const uint8 MAX_PROC_N = 64;



/*** private variables ***/

static Config config;







Result_t alloc_processors (Proc* res, 

                           const Config* conf)

{

  Result_t result;

  uint8_t  i;



  

  result = ALLOC_OK;



  for(i=0; (i < conf->num_proc) && (i < MAX_PROC_N); i++)

  {

    res = malloc(sizeof(Proc));



    if(res == NULL)

    {

      result = ALLOC_OUT_OF_MEMORY;

      break;

    }



    res++;

  }



  return result;

}

In this example written by a C programmer, config is initialized to NULL and there is no risk for integer overflow. If you want it idiot-programmer-proof, you can also add a check if(conf==NULL). I'm also really curious of knowing how a parameter to a function can go out of scope before the function is called.

Edited by: ESD editorial staff: SRambo on Apr 7, 2010 11:54 AM

4/8/2010 10:47 AM EDT

I think my C example is fairly similar to the Ada version in terms of code, except the Ada version of course uses more precise types.

Your C version is rather more involved, I would say. I do not object that you can write bullet-proof code in any language, rather I wanted to highlight that it is not as easy to write bullet-proof code in different languages. I think your C version confirms this. Plus it compiles despite a crucial bug: your parameter res should be a Proc** and you should be assigning the result of the allocation to *res.

To answer your question on how a parameter can be out-of-scope, here is a simple example:

int* wrong () {

  int i;

  return &i;

}



void do_something(int* p) {

  *p = 0;

}



void main() {

  do_something (wrong ());

}

4/9/2010 2:57 AM EDT

For the Ada version, you had set a limit for the maximum size of memory to be allocated, using a language-specific syntax. So does my C version, but your original C code does not. And oops... yes it should be pointer-to-pointer.

As for returning pointers to local variables, it indicates that they are beginner programmers. I really don't hope anyone professional encounter such code when running static analyzis on their soon-to-be production code.

In fact, if you return any kind pointer from a function in any C program, that is in my opinion a sign of bad design. The need of returning a pointer from a function originates from flawed logic. Instead, return data through pointers in one of the function parameters and leave the allocation of said parameters to the caller.

A pointer returned from a function can point at the following kind of variables:

- Local variables. This case is always a bug in the program.

- The same data as one of the parameters of the function. This is inefficient programming, as the same parameter will be used twice in the function, taking up unnecessary stack space when the function is called.

- Dynamically allocated variables. Returning pointers to variables that were dynamically allocated inside the function is one of the most common causes for memory leaks in C programs. Instead, leave allocation to the caller, as in the example (but use pointer-to-pointer :) ).

- Global/static variables. This is a bug in a multi-process environment, as it makes the function unsafe for multiple processes / ISRs. It also makes the function vulnerable to unspecified behavior, in case it is called like this:

print(func(), func()); /* where func is the function altering global resources */

Returning pointers to static file scope variables is also a flaw in the program design, as it breaks the encapsulation of private variables.

4/9/2010 5:04 AM EDT

Hello Lundin and others.

In your revised version of the C code, the types Result_t and uint8_t are compatible with each other in expressions, despite their different purposes. Indeed, they are compatible with every other enum and integer type and floats under most circumstances, under various confusing and inconsistent silent promotion rules. If you are lucky then you will sometimes get a warning, but you can't rely on it. Even the MISRA checker allows a Result_t to be assigned to a uint8_t, even though this almost certainly makes no sense. And in any any C-derived language (MISRA or not) you have to use one of a small fixed set of integer types that almost never have the appropriate range for the quantity in question. And as well as having inappropriate ranges, quantities that should never be assignment compatible or mixable in expressions (without explicit conversions) can be silently confused with each other.

C (unlike Ada) basically doesn't have array and enumeration types at all, just pointers, storage allocators and defines. Here is a real bug (with name changes and simplifications):

(some header file)

typedef enum { INACTIVE, DETECTION, ... } tState;

typedef struct { ... } tProcessingState;



(another file)

tProcessingState ActiveState[NUM_PROCESSORS];



...



if (ActiveState == INACTIVE) {

...

}

else {

...

}

--------------Editor's note: those are square brackets around the word "NUM_PROCESSORS" above. The comment system for some reason thinks they're links. --ESD magazine.-------------------


This compiles, passes MISRA checking, and makes no sense. The if test is never true (it should say "ActiveState[n] == INACTIVE)"). There isn't a real type tState, just a bunch of constants. INACTIVE, being the first one, has the value 0. ActiveState, used in an expression, is merely a pointer. Pointers can be compared with 0. This is all fundamentally bad.

Also, you cannot just dismiss returning a pointer to a local variable as a beginner's mistake. It can be done in less obvious ways, for one thing. But the main point is that it is obviously dangerous and should simply be forbidden. Ada has rules that are designed to prevent such a mistake from even compiling. They make it less permissive than C in this respect. This is a good thing.

C programming is a minefield of these sorts of bugs, most of which can not occur or can readily be precluded in Ada, in part because Ada has a proper type system. The amount of effort that is required to debug and gain confidence in a C program is much greater, and you end up relying a lot on conventions that are difficult to enforce, rather than rules that are checked mechanically (as your example shows). And on top of that C syntax is much harder to read. In my experience it is typically a lot more difficult to gain confidence in 10_000 line C projects than in 100_000 line Ada ones. I think that this is the main point of the article.



Edited by: ESD editorial staff: SRambo on Apr 9, 2010 9:52 AM

4/12/2010 4:00 PM EDT

Hello willc2010,

Your example reminds me of a similar one reported by Coverity's team (they build static analyzers) in a recent article (http://mags.acm.org/communications/201002/?folio=66&CFID=85833885&CFTOKEN=18821371)

Here it is:

if (getuid() != 0 && getuid == 0) {

  ErrorF("only root!");

  exit(1);

}

The error is that the second part of the test is always true, because it compares the address of a function to zero, instead of the result of calling this function and zero. Just missing ().

Because of the security implications of this bug, they say that finding it got them enormous press coverage. Almost funny when you realize how stupid (= easy to find) this bug is!