Type state analysis
Richard Andrew Cattermole (Rikki)
richard at cattermole.co.nz
Sun Mar 17 06:51:23 UTC 2024
This proposal introduces a new semantic pass, that uses an IR to
analyse memory transfers and the different states it can be in.
It is the bleading edge on program security, that would enable
other memory analysis solutions such as isolated (immutable
references ala Midori).
It enables:
- To prevent reads to uninitialized variables
- Prevent reads, writes, method calls to null objects
- Logic errors such as trying to read from an unopened file
- Is a framework to analyse unreachable vs reachable variables
It does not affect the type system.
Additional information must be provided by the user if they want
to go beyond the defaults.
The default type state of each variable is meant to be as close
to provable by the compiler, with user assistance like null
checks.
A key premise is that newer edition ``@safe`` function will not
be able to call the older ``@safe`` function.
This drastically simplifies decisions.
The end goal of this is to enable D to become temporally safe,
which is critical to D's future (see the recent US government
report on memory safety with specific mention towards temporal
safety).
Without this, the framework required to do temporal analysis does
not exist, and what would otherwise be very clear decisions
become arguable at best, at worst complete unknowns.
For each variable declaration I am proposing a default type
state, along with manual specification of the input and output
states it may be in by using the UAX31 Medial character
``identifier'input'output``.
This proposal was born out of necessaity after failure to solve
issues surrounding isolated, and it too required a similar IR to
be built.
I recognize that this could be a bit costly, but due to the
potential performance wins as well as memory and logic safety,
this is an absolute must if we want to be competitive.
Latest:
https://gist.github.com/rikkimax/eed86a7061445a93f214e41fb6445e40
Current:
https://gist.github.com/rikkimax/eed86a7061445a93f214e41fb6445e40/a8fffb5725904c6f5d74052d9c974a8f5d453fb0
More information about the dip.ideas
mailing list