Comments (6)
After a discussion separate pre and post conditions for callbacks are not feasible. The checks should happen in the application. This is both due to the fact that the platform code does not provide a full data flow in SPARK so that the callbacks are often called from C or outside SPARK mode which makes it possible to prove anything via preconditions. Also as the platform code is not proven and therefore it should not provide preconditions as they cannot be proven to be met.
from gneiss.
Also the generic contract function doesn't seem fully feasible as the preconditions also can hardly be established in the platform. Also the danger of an unsound proof is higher since the platform code is not fully proven.
from gneiss.
I think I found out why we could not prove those properties without a check in the callback. The session specific callbacks all provide a session identifier that tells who was the caller. What we tried to do is to prove somehow that the caller is always the only session object we have in our component package. But this is simply not possible since there could be some other session object that has been initialized with the same instance of the generic. So checking if the session was initialized was merely a proxy to the check if this has been called by our session (one that also only works if there is only one session). So instead of checking the initialization we should check if the caller is indeed our session and then we should be able to proof that all the properties of our session apply by annotating the identifier of our session with the same properties.
Example:
type Client_Session is limited private;
type Client_Instance is private;
Invalid_Instance : constant Client_Instance;
function Initialized (C : Client_Session) return Boolean;
function Initialized (C : Client_Instance) return Boolean with Ghost;
function Instance (C : Client_Session) return Client_Instance with
Contract_Cases => (Initialized (C) => Instance'Result /= Invalid_Instance,
not Initialized (C) => Instance'Result = Invalid_Instance);
Note that for this to work properly that Instance
must be callable on non initialized objects since we can only derive the instance from the object and not the other way round. If Instance
would require the session to be initialized we would have to do the check twice.
In a callback we then could do the following:
Session : Client_Session := Create;
procedure Callback (I : Client_Instance)
is
begin
if Instance (Session) = I then
pragma Assert (Initialized (Session));
end if;
end Callback;
What we can do here is to set a precondition to Callback
that I
is not invalid and then we can implicitly prove that Session
is initialized if I
is its identifier. But we still have to do the check that we use the correct session because the platform only enforces that whoever called this procedure is initialize but not that the known session has been calling it.
from gneiss.
For Linux and Genode the thin binding should get post conditions that are executed. As this requires runtime support the exceptions should be added manually.
from gneiss.
When using a global variable in a callback it can happen that a aliasing check fails if the callback is called from another procedure that takes the same global as an in out argument. In this case the global contract of the callback must denote the global variable as input and then the check can be marked as false positive. Unfortunately this also depends on the platform implementation and when callbacks are called (especially from where they're called).
Currently as far as I can tell all platforms call the same callbacks from the same procedure/function. It might be useful to add a comment to each procedure that calls a callback which one it calls and make this a rule that all platforms must follow.
This does not apply to callback functions as they do not alter global state at any time and can therefore be called always.
from gneiss.
Fixed by #87.
from gneiss.
Related Issues (20)
- Timer session on Linux HOT 1
- Consolidation HOT 1
- Prove tests HOT 9
- Prove broker HOT 1
- Fix file descriptor leaks
- Allow proving, editing and compiling as different commands in cement HOT 1
- Prove globals HOT 4
- Custom parameters for generic operations HOT 3
- GPIO Debug HOT 1
- Update ada-runtime, rename init to core/linux HOT 1
- Add support for different platforms to cement HOT 1
- Matrix Demo
- ICMP Demo HOT 4
- Update README HOT 1
- Global platform state for volatile inputs
- Update to CE 2020 HOT 5
- Update to RecordFlux 0.4.0 HOT 1
- Stream interface HOT 1
- Run checkers on cement
- SPI driver
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gneiss.