addr_eq versus = and <> in generated axioms access_update, access_update_neq
ID0001117:
**This issue was created automatically from Mantis Issue 1117. Further discussion may take place here.**
---
| **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** |
| --- | --- | --- | --- | --- | --- |
| ID0001117 | Frama-C | Plug-in > wp | public | 2012-03-12 | 2012-11-06 |
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| **Reporter** | Jochen | **Assigned To** | pherrmann | **Resolution** | fixed |
| **Priority** | normal | **Severity** | tweak | **Reproducibility** | always |
| **Platform** | - | **OS** | - | **OS Version** | - |
| **Product Version** | Frama-C Nitrogen-20111001 | **Target Version** | - | **Fixed in Version** | Frama-C Oxygen-20120901 |
### Description :
I ran "frama-c -wp -cpp-command 'gcc -C -E -I.' -pp-annot -wp-rte -wp-proof alt-ergo -no-unicode -wp-warnings -wp-out ./out ftest.c" on the attached program and inspected the generated file "out/store_ftest_post_1_po_ergo.why".
In the proof obligation for c-source line 14, the update operator a[i<-v] is used with e.g. addr_shift(s_0,0) substituted for i. In the axioms access_update and access_update_neq, arguments at position i are compared by built-in equality (and disequality <>).
However, terms starting with "addr_shift" are usually compared by "addr_eq", e.g. in the translation of lemma l.
I suggest to check whether the mentioned axioms should be weakened to:
axiom access_update : (forall a:'a1 farray.(forall i:int.(forall j:int.(forall v:'a1.(addr_eq(i,j) -> a[i<-v][j]=v)))))
axiom access_update_neq : (forall a:'a1 farray.(forall i:int.(forall j:int.(forall v:'a1.((not addr_eq(i,j)) -> (a[i<-v][j]=a[j]))))))
If not, I suggest to check whether addr_eq is in fact the same as =, and to drop the former for sake of simplicity.
## Attachments
- [ftest.c](/uploads/cd05b6376c9c0e2eb054fdb51936c97c/ftest.c)
issue