Coder Social home page Coder Social logo

Comments (6)

jklmnn avatar jklmnn commented on May 25, 2024

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.

jklmnn avatar jklmnn commented on May 25, 2024

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.

jklmnn avatar jklmnn commented on May 25, 2024

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.

jklmnn avatar jklmnn commented on May 25, 2024

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.

jklmnn avatar jklmnn commented on May 25, 2024

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.

jklmnn avatar jklmnn commented on May 25, 2024

Fixed by #87.

from gneiss.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.