Does Frama-C catch the UB of reading uninitialised stack variables?

Question

I'm exploring Frama-C and tried this example, which according to the manual (on page 83) should be Handled (CWE-457), and the RTE manual 2.7 (do ints have a trap representation? http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2091.htm) should be covered?

/*@ assigns \nothing; @*/
int f() {
  int a;
  return a;
}

/*@ assigns \nothing; @*/
int main() {
    if (f() < 0) {
        return 0;
    } else {
        return 1;
    }
}

#include<stdio.h>

/*@ assigns \nothing; @*/
char f() {
  char a;
  return a;
} 
                                                                                                                                                          
/*@ assigns \nothing; @*/
int main() {
  char s[2];
  s[0] = f();
  s[1] = '\0';
  puts(s);
  return 0;
}

However when I run these examples frama-c -wp -wp-rte they seem to pass. Is this intended behaviour?

score 2 · Accepted Answer · answered Jan 21 '22 at 17:18

As mentioned (admittedly not in a very prominent way) in the manual of the RTE plugin, in table 3.2 on p.20, the set of functions for which initialization-related assertions are generated is empty by default. The main reason is that it might generate a lot of assertions (basically each time a local variable that is not explicitly initialized is used), and users tend to be less interested in them than e.g. invalid pointer dereferences or arithmetic overflow.

If you want to generate them for all function, you need to use -rte-initialized @all on the Frama-C command line, as in: frama-c -wp -wp-rte -rte-initialized @all file.c. You can find more information about RTE's treatment of initialization assertions in section 2.7 of the manual.

Does Frama-C catch the UB of reading uninitialised stack variables?

1 Answers1