# Potential Odin Improvements
This is a compilations of Odin's functionality that potentially needs improvements.
## General
1. ### Making use of imports (aliases)
While Odin supports two versions of import syntax (with and without explicit aliasing), they are not treated as actual imports (no code gets imported from other files). The only time the imported statements are checked against is when the analyzers encounter a token that they have no information of.
2. ### Support for parametrized objects
None of the analyzers even consider objects with void attributes objects.
3. ### Support for parametrized decoration
None of the analyzers make use of decorations that have parametres.
For instance, direct access defect will not be detected in the following:
```
[a] > parent
a > state
[] > child
parent memory > @
[self] > method
3.sub ((self.state.add 10).add 10) > @
```
4. ### Source mapping
Odin AST does not store the location of the term in the source code.
## Mutual Recursion
1. False positives occur in sources with dead code or base cases.
```
[] > test
[] > base
memory > x
[self] > n
x.write 0 > @
[self] > m
self.n self > @
[] > derived
base > @
base.x > x
[self] > n
if. > @
TRUE
self.m self
x.write (x.add 1)
```
https://github.com/Polystat/awesome-bugs/blob/master/tests/inheritance/mutual-recursion-with-if-branching3.yml
https://github.com/Polystat/awesome-bugs/blob/master/tests/inheritance/mutual-recursion-with-random-if-branching.yml
2. The program crashes with a stack overflow when encountering circular inheritance:
```
[] > a
b > @
[] > b
a > @
```
## State access
1. Some obscure ways to create state are not accounted for:
```
[] > a
c1 > state
c2 > c1
cage > c2
[] > second_obj
a > @
[self] > func
self.state > @
```
OR
(only plain state is detected as of now)
```
[] > base
memory > plain_state
[some_number] > inner_state
some_number > n
memory > m
[] > very_inner_state
[] > hidden_state
m > @
memory > inner_mem
cage > inner_cage
[] > b
base > @
[self] > func
(self.inner_state 3).very_inner_state.hidden_state > super_tmp
self.inner_state.inner_cage > tmp
seq > @
self.plain_state.write 10
self.inner_state.inner_mem
```
2. Shadowing of key words is not accounted for
```
[memory] > parent
memory > state
[] > child
parent > @
[self] > method
3.sub ((self.state.add 10).add 10) > @
```
## Logic extraction
1. Sometimes the princess solver crashes when extracting logic for
methods without arguments even though the formula is correct.
EO:
```
[] > base
[self x] > util
x > @
[self] > n
self.util self 10 > @
[] > derived
base > @
[self x] > util
seq > @
assert (x.less 10)
x
```
SMT:
```
(define-fun properties-of-child-util ((var-child-x Int)) Bool (and true true))
(define-fun value-of-parent-util ((var-parent-x Int)) Int var-parent-x)
(define-fun properties-of-parent-util ((var-parent-x Int)) Bool (and true true))
(define-fun value-of-child-util ((var-child-x Int)) Int var-child-x)
(define-fun value-of-child-n () Int (value-of-child-util 10))
(define-fun properties-of-child-n () Bool (and (properties-of-child-util 10) true))
(define-fun properties-of-parent-n () Bool (and (properties-of-parent-util 10) true))
(define-fun value-of-parent-n () Int (value-of-parent-util 10))
(assert (=> (and (properties-of-parent-util 10) true) (and (properties-of-child-util 10) true)))
```
2. Current implementation makes it impossible to store boolean values in object fields. Only integer values are supported as of now.
3. No checks are performed on the contents of asserts in EO. As such, it is possible to assert an integer value, which would cause unanticipated behavior. For example, assert (3.add 5).
## Unjustified assumptions
1. Method pairs for inspection are formed by considering only direct descendants. For example, in case of an inheritance chain A -> B -> C only combinations (A,B) and (B,C) are examined. It would be ideal to examine all possible combinations. So, in the given example an additional pair (A,C) is to be examined.