frama-c issueshttps://git.frama-c.com/pub/frama-c/-/issues2023-11-08T18:21:33Zhttps://git.frama-c.com/pub/frama-c/-/issues/2672Handling of wide string literals2023-11-08T18:21:33ZMarvin HäuserHandling of wide string literals### Steps to reproduce the issue
Evaluate `sizeof(L"AA")` during preprocessing, possibly as part of a `_Static_assert`. Take for example the following code snippet:
```
_Static_assert(sizeof(L"AA") == 12, "Incorrect sizeof behaviour");...### Steps to reproduce the issue
Evaluate `sizeof(L"AA")` during preprocessing, possibly as part of a `_Static_assert`. Take for example the following code snippet:
```
_Static_assert(sizeof(L"AA") == 12, "Incorrect sizeof behaviour");
int main(void){}
```
This compiles fine with GCC, but fails preprocessing with ``frama-c -wp``. With varying string lengths, the assertion succeeds Frama-C preprocessing when replacing 12 with the pointer size, but fails to compile with GCC.
### Expected behaviour
The expression evaluates to `sizeof(wchar_t) * 3`, typically 12.
### Actual behaviour
The expression evaluates to `sizeof(wchar_t *)`, typically 4 or 8.
### Contextual information
- Frama-C installation mode: Opam
- Frama-C version: 27.1 (Cobalt)
- Plug-in used: WP
- OS name: macOS
- OS version: 14.0
### Additional information (optional)
A quick search of the source code yields several special handling of string literals, e.g. the definition of `SizeOfStr()`. It appears most to all of the related code is specific to `char` string literals with no support for `wchar_t` string literals (both as in they do not seem to get special handling, and there is no support in the existing literal code to vary the character size). As I am new to the codebase, please feel free to confirm or correct my observations. Thank you!Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/2597[WP] Out of memory crash2022-04-20T07:18:53ZLélio Brun[WP] Out of memory crash### Steps to reproduce the issue
Here is a (not necessarily) minimal example (see [excludes.c](/uploads/af45da85624b741546d0e395a330d1e5/excludes.c)):
```c
void excludes8(_Bool x1, _Bool x2, _Bool x3, _Bool x4,
_Bool x...### Steps to reproduce the issue
Here is a (not necessarily) minimal example (see [excludes.c](/uploads/af45da85624b741546d0e395a330d1e5/excludes.c)):
```c
void excludes8(_Bool x1, _Bool x2, _Bool x3, _Bool x4,
_Bool x5, _Bool x6, _Bool x7, _Bool x8,
_Bool *excludes)
{
*excludes =
(!x1 && !x2 && !x3 && !x4 && !x5 && !x6 && !x7 && !x8) ||
( x1 && !x2 && !x3 && !x4 && !x5 && !x6 && !x7 && !x8) ||
(!x1 && x2 && !x3 && !x4 && !x5 && !x6 && !x7 && !x8) ||
(!x1 && !x2 && x3 && !x4 && !x5 && !x6 && !x7 && !x8) ||
(!x1 && !x2 && !x3 && x4 && !x5 && !x6 && !x7 && !x8) ||
(!x1 && !x2 && !x3 && !x4 && x5 && !x6 && !x7 && !x8) ||
(!x1 && !x2 && !x3 && !x4 && !x5 && x6 && !x7 && !x8) ||
(!x1 && !x2 && !x3 && !x4 && !x5 && !x6 && x7 && !x8) ||
(!x1 && !x2 && !x3 && !x4 && !x5 && !x6 && !x7 && x8);
//@ assert *excludes == 1;
return;
}
```
Launch Frama-C / WP: `frama-c -wp excludes.c`
### Expected behaviour
The (silly) assertion should be tried by the solvers.
### Actual behaviour
Out of memory crash (on a 16G laptop):
```
[kernel] Parsing FIREFLY_1.c (with preprocessing)
[wp] Warning: Missing RTE guards
[wp] 1 goal scheduled
'frama-c -wp FIREFLY_1.c' terminated by signal SIGKILL
```
### Contextual information
- Frama-C installation mode: opam
- Frama-C version: 24.0 (Chromium)
- Plug-in used: WP
- OS name: Ubuntu
- OS version: 20.04.4 LTS
- Memory: 15605 MiB
### Additional information (optional)
I tried to profile the execution by using [Memtrace](https://github.com/janestreet/memtrace) on a local installation of Frama-C. It seems that WP is filling huge identifiers tables ([Intmap](https://git.frama-c.com/pub/frama-c/-/blob/24.0/src/plugins/qed/intmap.ml#L273), [Idxmap](https://git.frama-c.com/pub/frama-c/-/blob/24.0/src/plugins/qed/idxmap.ml#L72)) when executing code from [Conditions](https://git.frama-c.com/pub/frama-c/-/blob/24.0/src/plugins/wp/Conditions.ml) module.
Here is the corresponding trace, that can be viewed using [Memtrace_viewer](https://github.com/janestreet/memtrace_viewer): [trace.ctf](/uploads/42173f2b5017d16f12a46cf943dc09e7/trace.ctf)Allan BlanchardAllan Blanchardhttps://git.frama-c.com/pub/frama-c/-/issues/2596[WP] Type mismatch with Real model2022-03-15T12:28:29ZLélio Brun[WP] Type mismatch with Real model### Steps to reproduce the issue
Here is a minimal example (see [foo.c](/uploads/a0892900e8240b95c1623e300679efa2/foo.c)):
```c
//@ predicate Foo(double y) = y == 0.0;
void foo(double x) {
//@ assert Foo((double) (0.0 + 0.0 * x));
...### Steps to reproduce the issue
Here is a minimal example (see [foo.c](/uploads/a0892900e8240b95c1623e300679efa2/foo.c)):
```c
//@ predicate Foo(double y) = y == 0.0;
void foo(double x) {
//@ assert Foo((double) (0.0 + 0.0 * x));
}
```
Launch Frama-C / WP with Real model: `frama-c -wp -wp-model real foo.c`
### Expected behaviour
No error (as for `frama-c -wp foo.c`):
```
[kernel] Parsing foo.c (with preprocessing)
[wp] Warning: Missing RTE guards
[wp] 1 goal scheduled
[wp] [Cache] found:1
[wp] Proved goals: 1 / 1
Qed: 0
Alt-Ergo 2.4.1: 1 (56ms) (400) (cached: 1)
[wp:pedantic-assigns] foo.c:3: Warning:
No 'assigns' specification for function 'foo'.
Callers assumptions might be imprecise.
```
### Actual behaviour
Type mismatch error:
```
[kernel] Parsing foo.c (with preprocessing)
[wp] Warning: Missing RTE guards
[wp] 1 goal scheduled
[wp] [Alt-Ergo 2.4.1] Goal typed_real_foo_assert : Failed
[Why3 Error] Type mismatch between real and int
[wp] [Cache] not used
[wp] Proved goals: 0 / 1
Alt-Ergo 2.4.1: 0 (failed: 1)
[wp:pedantic-assigns] foo.c:3: Warning:
No 'assigns' specification for function 'foo'.
Callers assumptions might be imprecise.
```
Indeed, we can see with `frama-c-gui` in Script mode that the expression is simplified to `0`, as we are given the following proof context:
```
Goal Assertion:
Prove: P_Foo(0).
```
### Contextual information
- Frama-C installation mode: Opam
- Frama-C version: 24.0 (Chromium)
- Plug-in used: WP
- OS name: Ubuntu
- OS version: 20.04.4 LTS
### Additional information
Removing the addition works:
```c
//@ predicate Foo(double y) = y == 0.0;
void foo(double x) {
//@ assert Foo((double) (0.0 * x));
}
```Allan BlanchardAllan Blanchardhttps://git.frama-c.com/pub/frama-c/-/issues/2459Frama-C fails to parse a file2022-12-28T10:05:19Zmantis-gitlab-migrationFrama-C fails to parse a fileID0000261:
**This issue was created automatically from Mantis Issue 261. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- ...ID0000261:
**This issue was created automatically from Mantis Issue 261. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0000261 | Frama-C | Kernel | public | 2009-10-01 | 2009-10-01 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jonathan-Christofer Demay | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Beryllium-20090901 | **Target Version** | - | **Fixed in Version** | - |
### Description :
It compiles fine with "gcc -I. -I./libtomcrypt/src/headers/ -DDROPBEAR_SERVER -DDROPBEAR_CLIENT dbutil.c -c -o dbutil.o"
But when given to Frama-C (CPP is set accordinly), I get the following error:
libtommath/tommath.h:77:[kernel] user error: GCC width mode TI applied to unexpected type, or unexpected mode
In tommath.h line 77 we have a mysterious GCC incantation (>_<):
typedef unsigned long mp_word __attribute__ ((mode(TI)));
### Additional Information :
Uploaded a preprocessed file: "gcc -I. -I./libtomcrypt/src/headers/ -DDROPBEAR_SERVER -DDROPBEAR_CLIENT dbutil.c -C -E -o dbutil.i"
## Attachments
- [dbutil.i](/uploads/ca1ba34059bd1dd4efa823437f09a2c6/dbutil.i)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/2347Parse error when using a wide string literal to initialize uint16 array2021-02-22T13:56:58Zmantis-gitlab-migrationParse error when using a wide string literal to initialize uint16 arrayID0000593:
**This issue was created automatically from Mantis Issue 593. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- ...ID0000593:
**This issue was created automatically from Mantis Issue 593. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0000593 | Frama-C | Kernel | public | 2010-09-30 | 2010-10-01 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Maria | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
I'm trying to analyze Brew with Frama-C. OS - windows XP.
I've created simple Brew project(see attach), preprocessed it with Visual Studio and after it try to analyze with Frama-C:
C:\Frama-C\bin>frama-c.exe "\Program Files\BREW 3.1.5\sdk\examples\helloworld"\*.i
Also, I've tried to add files to project, using user interface, but nothing happened.
## Attachments
- [helloworld.zip](/uploads/e1faf5861730eaa7d75da589b90c18c6/helloworld.zip)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/2324Empty specification causes syntax error2021-02-22T13:56:32Zmantis-gitlab-migrationEmpty specification causes syntax errorID0000605:
**This issue was created automatically from Mantis Issue 605. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- ...ID0000605:
**This issue was created automatically from Mantis Issue 605. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0000605 | Frama-C | Kernel > ACSL implementation | public | 2010-10-13 | 2010-12-16 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | boris | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Boron-20100401 | **Target Version** | - | **Fixed in Version** | - |
### Description :
File [1] causes error [2] when processed with frama-c -val. However, processing with frama-c -jessie causes no errors.
### Additional Information :
[1]
int* p;
int foo();
/*@
*/
int main() {
int i, t[10];
for(i=0; i<=10; i++)
t[i]=i;
if(foo()) p[2] = 1;
return 0;
}
[2]
[kernel] preprocessing with "gcc -C -E -I. val1.c"
val1.c:6:[kernel] user error: syntax error while parsing annotation
[kernel] user error: skipping file "val1.c" that has errors.
[kernel] Frama-C aborted because of an invalid user input.Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/2255Strange AST produced with unspecified side-effects involve function calls in ...2021-02-22T14:02:55ZPascal CuoqStrange AST produced with unspecified side-effects involve function calls in expressionsID0000676:
**This issue was created automatically from Mantis Issue 676. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- ...ID0000676:
**This issue was created automatically from Mantis Issue 676. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0000676 | Frama-C | Kernel | public | 2011-01-18 | 2011-01-18 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | pascal | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Carbon-20101202-beta2 | **Target Version** | - | **Fixed in Version** | - |
### Description :
Original code:
if(((fast_read(o, 3) ^ fetch) & 0xffffff) == 0 && o < src - MINOFFSET)
Transformed as:
ui32 tmp_1 ;
{ /*undefined sequence*/
tmp_1 = fast_read((void const *)o,(unsigned int )3);
;
}
if (((tmp_1 ^ fetch) & (unsigned int )0xffffff) == (unsigned int )0) {
if (o < src - 2) {
Contact Pascal for whole function.Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/2045__builtin_alloca2021-02-22T13:49:38Zmantis-gitlab-migration__builtin_allocaID0001190:
**This issue was created automatically from Mantis Issue 1190. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0001190:
**This issue was created automatically from Mantis Issue 1190. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0001190 | Frama-C | Kernel | public | 2012-06-08 | 2012-06-09 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Anne | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | have not tried |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Nitrogen-20111001 | **Target Version** | - | **Fixed in Version** | - |
### Description :
In a file with a local array which size in defined by a variable :
float a[n];
I get :
[kernel] warning: Variable-sized local variable a
which is ok. But then, when I use the value analysis, I get :
[kernel] warning: No code for function __builtin_alloca,
default assigns generated
because the declaration has been translated in :
__lengthofa = (unsigned int)n;
a = (float *)__builtin_alloca(sizeof(*a) * __lengthofa);
which looks fine, but the question is :
shouldn't the assigns property be defined somewhere inside Frama-C for the builtin functions ?
As a workaround, what prototype and assigns should I write for this function.Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/1926Code annotation in the middle of labels2021-03-29T13:52:50ZJulien SignolesCode annotation in the middle of labelsID0001327:
**This issue was created automatically from Mantis Issue 1327. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0001327:
**This issue was created automatically from Mantis Issue 1327. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0001327 | Frama-C | Kernel | public | 2012-12-12 | 2012-12-12 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | signoles | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
Consider this code:
void foo(int x) {
switch (x) {
case 0: /*@ assert \true; */
case 1: ;
}
}
Frama-C encloses both the assertion and the "case 1: ;" into a block inside the "case 0" as shown below. I'm not sure that it is the expected behavior (either the block should also include "case 0" or this program should be rejected as syntactically incorrect).
$ frama-c -kernel-debug 1 a.i
<skip trace>
/* Generated by Frama-C */
void foo(int x)
{
/* */
/*sid:2*/
switch (x) {
/* */
case 0:
/*sid:3*/
/*block:begin*/
{
/* */
/*sid:4*/ /*@ assert \true; */ ;
case 1: /*sid:5*/ ; }
/*block:end*/
}
/*sid:8*/
return;
}
Note: if you add a semi-colon right after the assertion, there is no issue.Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/1137Initializer of static variable refers to size of type of local variable2021-02-22T13:48:28ZPascal CuoqInitializer of static variable refers to size of type of local variableID0001645:
**This issue was created automatically from Mantis Issue 1645. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0001645:
**This issue was created automatically from Mantis Issue 1645. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0001645 | Frama-C | Kernel | public | 2014-02-13 | 2014-03-24 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | pascal | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | low | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Fluorine-20130601 | **Target Version** | - | **Fixed in Version** | - |
### Description :
CONTEXT:
This issue does not originate from an industrial application. It is reported for the lulz.
DESCRIPTION:
The program below is accepted by gcc and clang, and rejected by Frama-C. It seems that the compilers are right to accept it.
~ $ cat t.c
unsigned f(void) {
int a;
static unsigned s = sizeof(a);
return s;
}
~ $ clang -std=c99 -pedantic -Wall -c t.c
~ $ frama-c t.c
[kernel] preprocessing with "gcc -C -E -I. t.c"
t.c:4:[kernel] user error: Forbidden access to local variable a in static initializer
[kernel] user error: skipping file "t.c" that has errors.
[kernel] Frama-C aborted: invalid user input.
~ $Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/1034option -nostdinc does not seem to work2021-02-22T14:02:33ZJens Gerlachoption -nostdinc does not seem to workID0001786:
**This issue was created automatically from Mantis Issue 1786. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0001786:
**This issue was created automatically from Mantis Issue 1786. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0001786 | Frama-Clang | Kernel | public | 2014-05-26 | 2014-05-27 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | jens | **Assigned To** | virgile | **Resolution** | no change required |
| **Priority** | normal | **Severity** | major | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Neon-20140301 | **Target Version** | - | **Fixed in Version** | - |
### Description :
When calling the following sample code (nostdinc.cpp)
#include "limits.h"
int foo(int a)
{
if (a >= INT_MAX/2)
return INT_MAX;
else
return a;
}
with
frama-c-gui -cpp-command 'gcc -C -E -nostdinc -I/usr/local/share/frama-c/libc' -cxx-clang-command="framaCIRGen" -cxx-stdinc -cxx-demangling-full -wp -wp-rte -wp-proof alt-ergo nostdin.cpp
refers to std header such as
In file included from nostdin.cpp:2:
In file included from /usr/include/clang/3.3/include/limits.h:38:
In file included from /usr/include/limits.h:25:
In file included from /usr/include/features.h:398:
/usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
# include <gnu/stubs-32.h>
^Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/955Translation of abrupt clause into assert do not take 'for :' clause into account2021-02-22T13:51:40ZVirgile PrevostoTranslation of abrupt clause into assert do not take 'for :' clause into accountID0001632:
**This issue was created automatically from Mantis Issue 1632. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0001632:
**This issue was created automatically from Mantis Issue 1632. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0001632 | Frama-C | Kernel > ACSL implementation | public | 2014-01-27 | 2014-10-29 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | virgile | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | low | **Severity** | minor | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C GIT, precise the release id | **Target Version** | - | **Fixed in Version** | - |
### Description :
In the program written given below, the returns clause is translated into two assert that are not related to the foo behavior, resulting in an unprovable assertion in the else branch.
### Steps To Reproduce :
/*@ behavior foo:
assumes a == 0;
*/
int foo(int a) {
/*@ for foo:
returns \result == 0;
*/
{ if (a==0) { return 0; }
else return 2;
}
}Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/907axiom "addr_le_def" given to Alt-Ergo considered too weak2021-08-05T14:15:00ZJochen Burghardtaxiom "addr_le_def" given to Alt-Ergo considered too weakID0002047:
**This issue was created automatically from Mantis Issue 2047. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002047:
**This issue was created automatically from Mantis Issue 2047. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002047 | Frama-Clang | Plug-in > wp | public | 2015-01-12 | 2015-02-12 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | correnson | **Resolution** | open |
| **Priority** | normal | **Severity** | major | **Reproducibility** | always |
| **Platform** | Jan2015-Neon-20140301+dev-STANC | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
The loop invariant "xx5" of the attached program "fill1.c" can't be proven with Alt-Ergo. The goal reads fine, viz.:
goal fill_loop_inv_xx5_preserved:
forall a_3,a_2,a_1,a : addr.
(a_1 <> a_2) ->
addr_le(a_3, a_2) ->
(region(a.base) <= 0) ->
(region(a_3.base) <= 0) ->
addr_le(a_3, shift_sint16(a_2, 1))
However, the axiom "addr_le_def" appears to be too weak, it currently reads:
axiom addr_le_def :
(forall p:addr. forall q:addr [addr_le(p, q)]. (((p).base = (q).base) ->
(addr_le(p, q) -> ((p).offset <= (q).offset))))
While the loop inveriant certainly should be provable, I don't see any way to prove a_3.base=a_2.base with the current version of the file.
Moreover, in order for axioms "addr_le_def" and "addr_le_def1" to be a definition of "addr_le(.,.)" in terms of "=" and "<=" etc., axiom "addr_le_def" should be changed to:
axiom addr_le_def :
(forall p:addr. forall q:addr [addr_le(p, q)].
(addr_le(p, q) -> p.base = q.base and p.offset <= q.offset))
After that change, Alt-Ergo proves the goal without any problems. The attached file "fill_loop_inv_xx5_preserved_Alt-Ergo.mlw" contains the changed version in a comment at line 408.
If my argument is right, the whole axiomatization should be reviewed to remove similar flaws, which give Frama-C a rather poor performance on address arithmetic. (For that reason, I assigned a higher severity.)
### Additional Information :
Originally, I'd submitted this issue to the Alt-Ergo issue tracker, see https://github.com/OCamlPro/alt-ergo/issues/9. I'm indebted to Mohamed Iguernelala for hinting at the weak axiom "addr_le_def", where I had a blind spot.
## Attachments
- [fill1.c](/uploads/e5ff187165a5e10b7858e1f325eea68a/fill1.c)
- [fill_loop_inv_xx5_preserved_Alt-Ergo.mlw](/uploads/6292554fc2953d67792737e6dac31199/fill_loop_inv_xx5_preserved_Alt-Ergo.mlw)
- [fill.c](/uploads/c1dcc11d568e2e09d95aeabf0b9df093/fill.c)
- [fill4.c](/uploads/5ce99f117503a2df12c827af1b439520/fill4.c)
- [fill5.c](/uploads/ece00cbe919a18c0800d32b0adb27fb2/fill5.c)
- [fill4r.c](/uploads/81225ff5f9ecee0d89645919cbe59e44/fill4r.c)
- [find_arr.c](/uploads/fec90cf4fecefaee9a7cea344c14b693/find_arr.c)
- [find_ptr.c](/uploads/8430a7bbd76c8f263bd433d3cfd746d8/find_ptr.c)
- [find_ptr_foo_post_Alt-Ergo_modified.mlw](/uploads/d52e028cdf21562b07c9e340031cef8c/find_ptr_foo_post_Alt-Ergo_modified.mlw)Loïc CorrensonLoïc Corrensonhttps://git.frama-c.com/pub/frama-c/-/issues/906exception identifier from catch() statement unknown in contracts, but not in ...2021-02-22T13:28:04ZJochen Burghardtexception identifier from catch() statement unknown in contracts, but not in codeID0002071:
**This issue was created automatically from Mantis Issue 2071. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002071:
**This issue was created automatically from Mantis Issue 2071. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002071 | Frama-Clang | Plug-in > clang | public | 2015-02-02 | 2015-02-13 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | Neon-20140301+dev-STANCE-Jan2015 | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
output:
[kernel] Parsing FRAMAC_SHARE/libc/__fc_builtin_for_normalization.i (no preprocessing)
[kernel] Parsing 447.cpp (external front-end)
447.cpp:6:17: unknown identifier 'e'
Now output intermediate result
The message disappears if the "assert" in line 6 is deactivated.
## Attachments
- [447.cpp](/uploads/25b6f25f7846390e808821adc8820019/447.cpp)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/903can't compare pointer and reference for equality in contract2021-02-22T13:14:31ZJochen Burghardtcan't compare pointer and reference for equality in contractID0002060:
**This issue was created automatically from Mantis Issue 2060. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002060:
**This issue was created automatically from Mantis Issue 2060. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002060 | Frama-Clang | Plug-in > clang | public | 2015-01-22 | 2015-02-14 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | Neon-20140301+dev-STANCE-Jan2015 | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
output:
[kernel] Parsing FRAMAC_SHARE/libc/__fc_builtin_for_normalization.i (no preprocessing)
[kernel] Parsing 441.cpp (external front-end)
441.cpp:2:22: invalid implicit conversion
441.cpp:2:22: unknown type comparison for the operator ==
Now output intermediate result
When line 2 is commented out, the comparison in C++ code in line 3 is accepted.
## Attachments
- [441.cpp](/uploads/da2cc8f3623d5563d069827341da0b18/441.cpp)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/897recursive logic integer function definition causes error2021-02-22T13:27:11ZJochen Burghardtrecursive logic integer function definition causes errorID0002050:
**This issue was created automatically from Mantis Issue 2050. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002050:
**This issue was created automatically from Mantis Issue 2050. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002050 | Frama-Clang | Plug-in > clang | public | 2015-01-15 | 2015-02-14 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | Neon-20140301+dev-STANCE-Jan2015 | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
output:
431.cpp:2:56: unknown identifier 'fac'
Now output intermediate result
The problem disappears when the file is renamed to "431.c".
## Attachments
- [431.cpp](/uploads/50a3448bd9c7ec87a3c7205370803f6e/431.cpp)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/896ACSL comment rejected in function template2021-02-22T13:27:13ZJochen BurghardtACSL comment rejected in function templateID0002048:
**This issue was created automatically from Mantis Issue 2048. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002048:
**This issue was created automatically from Mantis Issue 2048. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002048 | Frama-Clang | Plug-in > clang | public | 2015-01-12 | 2015-02-14 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | Neon-20140301+dev-STANCE-Jan2015 | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
output:
[kernel] Parsing FRAMAC_SHARE/libc/__fc_builtin_for_normalization.i (no preprocessing)
[kernel] Parsing 430.cpp (external front-end)
inadequate comment at 430.cpp:5:2
If line 2 is commented-in and line 3 is commented-out, the error message disappears.
## Attachments
- [430.cpp](/uploads/fb7c1b9a2c7e740eb0e5c7200661ce99/430.cpp)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/895unprovable obligation generated for "ensures" in presence of exceptions2021-02-22T13:14:24ZJochen Burghardtunprovable obligation generated for "ensures" in presence of exceptionsID0002046:
**This issue was created automatically from Mantis Issue 2046. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002046:
**This issue was created automatically from Mantis Issue 2046. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002046 | Frama-Clang | Plug-in > clang | public | 2015-01-08 | 2015-02-14 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | frama-c-Neon-20140301+dev-STANCE | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
Running "frama-c -wp 429.cpp" on the attached program, the goal "typed__Z3bari_post_part1" cannot be proven by Alt-Ergo, i.e. it can't be proven that the postcondition of "foo" implies that of "bar" if the former doesn't throw an exception.
The goal in the file "_Z3bari_post_part1_Alt-Ergo.mlw" reads:
585 goal _Z3bari_post_part1:
586 forall i : int.
587 forall f : S___fc_exn_struct.
588 let x = (f.F___fc_exn_struct_exn_uncaught) : int in
589 (1 <> x) ->
590 is_sint32(i) ->
591 is_sint32(f.F___fc_exn_struct_exn_kind) ->
592 is_sint32(x) ->
593 ((0 = x) -> (42 <= i)) ->
594 (24 <= i)
If line 589 is changed to "(0 = x) ->", Alt-Ergo can prove it without problems; likewise if line 593 is changed to "((1 <> x) -> (42 <= i)) ->".
## Attachments
- [429.cpp](/uploads/8924b97702a6b0ba13c4daf1f56285ca/429.cpp)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/894throw without argument causes crash2021-02-22T13:41:11ZJochen Burghardtthrow without argument causes crashID0002045:
**This issue was created automatically from Mantis Issue 2045. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002045:
**This issue was created automatically from Mantis Issue 2045. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002045 | Frama-Clang | Plug-in > clang | public | 2015-01-08 | 2015-02-14 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | frama-c-Neon-20140301+dev-STANCE | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
output:
Now output intermediate result
[kernel] Current source was: 428.cpp:2
The full backtrace is:
Raised at file "stack.ml", line 36, characters 20-25
Called from file "src/kernel/exn_flow.ml", line 98, characters 23-44
Called from file "src/kernel/visitor.ml", line 75, characters 14-33
Called from file "cil/src/cil.ml", line 2046, characters 15-31
Called from file "cil/src/cil.ml", line 3095, characters 5-86
Called from file "cil/src/cil.ml", line 2085, characters 13-16
Called from file "cil/src/cil.ml", line 3255, characters 16-40
Called from file "cil/src/cil.ml", line 2061, characters 21-41
Called from file "cil/src/cil.ml", line 3484, characters 14-39
Called from file "cil/src/cil.ml", line 2061, characters 21-41
Called from file "cil/src/cil.ml", line 3446, characters 5-91
Called from file "cil/src/cil.ml", line 3538, characters 16-38
Called from file "cil/src/cil.ml", line 2085, characters 13-16
Called from file "cil/src/cil.ml", line 2130, characters 24-57
Called from file "cil/src/cil.ml", line 3532, characters 5-53
Called from file "cil/src/cil.ml", line 6151, characters 16-36
Called from file "list.ml", line 69, characters 12-15
Called from file "cil/src/cil.ml", line 5741, characters 3-30
Called from file "cil/src/cil.ml", line 6152, characters 2-420
Called from file "cil/src/cil.ml", line 2061, characters 21-41
Called from file "cil/src/cil.ml", line 6185, characters 7-84
Called from file "src/kernel/visitor.ml", line 827, characters 2-45
Called from file "src/kernel/file.ml", line 1803, characters 2-8
Called from file "queue.ml", line 134, characters 6-20
Called from file "src/kernel/file.ml", line 1880, characters 2-36
Called from file "src/kernel/file.ml", line 2372, characters 4-27
Called from file "src/kernel/ast.ml", line 111, characters 2-28
Called from file "src/kernel/ast.ml", line 123, characters 53-71
Called from file "src/kernel/boot.ml", line 29, characters 6-20
Called from file "src/kernel/cmdline.ml", line 761, characters 2-9
Called from file "src/kernel/cmdline.ml", line 216, characters 4-8
Unexpected error (Stack.Empty).
Please report as 'crash' at http://bts.frama-c.com/.
Your Frama-C version is Neon-20140301+dev-STANCE.
## Attachments
- [428.cpp](/uploads/ec15e3525df0c4c9340947fc89b631c9/428.cpp)Virgile PrevostoVirgile Prevostohttps://git.frama-c.com/pub/frama-c/-/issues/885constructor overloading resolution with templates causes dubious "contract me...2021-02-22T13:27:09ZJochen Burghardtconstructor overloading resolution with templates causes dubious "contract merge" warningID0002043:
**This issue was created automatically from Mantis Issue 2043. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | ---...ID0002043:
**This issue was created automatically from Mantis Issue 2043. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0002043 | Frama-Clang | Plug-in > clang | public | 2015-01-05 | 2015-02-15 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | virgile | **Resolution** | open |
| **Priority** | normal | **Severity** | minor | **Reproducibility** | always |
| **Platform** | frama-c-Neon-20140301+dev-stance | **OS** | - | **OS Version** | xubuntu-cfe13.10 |
| **Product Version** | - | **Target Version** | - | **Fixed in Version** | - |
### Description :
Running "frama-c -wp 426.cpp" produces the output:
Now output intermediate result
426.cpp:5:[kernel] warning: found two contracts. Merging them
[wp] Running WP plugin...
The warning remains if
(1) the contract in line 7 is activated, or
(2) the contract in line 11 is deactivated.
The warning disappears if
(3) lines 4-5 are deleted,
(4) line 8 is deleted, or
(5) "char" is changed to "int" in line 13.
Even if the warning is printed, the proof obligation for the constructor call in line 13 seems to be correct, viz.:
(* ---------------------------------------------------------- *)
(* --- Instance of 'Pre-condition (file 426.cpp, line 4) in '_ZN7complexIcEEC1vci'' in 'main' at call '_ZN7complexIcEEC1vci' (file 426.cpp, line 13)
--- *)
(* ---------------------------------------------------------- *)
goal main_call__ZN7complexIcEEC1vci_pre:
forall i : int.
forall t : int farray.
(i <= 6) ->
linked(t) ->
is_sint32(i) ->
(1 = i)
So it is not clear which contracts are merged. Possibly this is a revival of issue #1611. However, it could also indicate that the contract in line 4 is merged with the (empty) contract of the constructor in line 8 (since the warning disappears when line 8 is removed) - which would be wrong in general.
## Attachments
- [426.cpp](/uploads/83b16ec11a724e4803101543fe3e06de/426.cpp)Virgile PrevostoVirgile Prevosto