Comments for David Crocker's Verification Blog

Comment on Dynamic Memory Allocation in Critical Embedded Systems by Five things I never use in Arduino projects | David Crocker's Solutions blog

Sun, 16 Oct 2011 12:21:09 +0000

[...] a short while, but crashes with other inputs or after a longer time, due to memory exhaustion. See http://critical.eschertech.com/2010/07/30/dynamic-memory-allocation-in-critical-embedded-systems/ for more about why dynamic memory allocation is a bad idea in embedded software implemented in [...]

Comment on Verifying pointer arithmetic by Verifying programs that use function pointers « David Crocker's Verification Blog

Thu, 08 Sep 2011 14:03:18 +0000

[...] as pointer arithmetic can be verified if you make some extra effort writing the specifications (see Verifying pointer arithmetic), so can well-designed code using function pointers. In this post I’ll show how you can do [...]

Comment on Using C++ classes in critical software by Anshu Kadam

Anshu Kadam — Wed, 03 Aug 2011 18:27:57 +0000

A good article on some runtime critical errors. May be of some help.

http://www.experts-linked.com/content/runtime-error-critical-softwares

Comment on Verifying loops: proving termination by davidcrocker

davidcrocker — Sat, 02 Jul 2011 08:04:23 +0000

We intend to automatically infer the loop variant and the simpler parts of the loop invariant of a for-loop with a counter, where the counter is not modified in the loop body. Inferring the full loop invariant is a hard problem in the general case.

Comment on Verifying loops: proving termination by Dave Banham

Dave Banham — Wed, 29 Jun 2011 08:42:11 +0000

David,
Do you have plans to allow eCv to automatically infer the loop invariant and the loop decrement for simple loops? A recent ACM article (June 2011, Vol 64 #6) about indicates that Spec# is capable of doing this.

Comment on Safer arrays: using a C++ array class by davidcrocker

davidcrocker — Mon, 18 Apr 2011 16:37:22 +0000

Have you looked at the code for both debug and release builds? In a debug build (i.e. compiler optimization disabled) I would expect each different instantiation to get separate code. In a release build (i.e. optimization enabled) I would expect most of the member functions to get inlined because they are so simple. Code sharing for those functions is not an issue. You may also find that code that is not inlined but does not depend on _C_SIZE gets shared between instantiations, depending on the compiler. If that isn’t the case and you find there is lots of duplicate code even with compiler optimization enabled, then you could write yor own array class, with the code you want to share declared in a non-templated base class.

Comment on Safer arrays: using a C++ array class by henning laursen

henning laursen — Mon, 18 Apr 2011 11:24:35 +0000

(same as above but with escape-code for <>)

Each time I create a new array with a different size, the compiler creates a new code-base for that array size, because the size is a part of the array type. For example:

Std::array MyUC_10;
Std::array MyUC_20;
Std::array MyUC_30;

All get their own code base. Is there any way to avoid this type of compiler behaviour?
I would like all of the above to reference the same code-base.
As a test I created:

Templateclass MyTest
{
Public:
_T_base _myVal;
};

MyTest T1;
MyTest T2;

In the test I do not utilize/reference _C_Size any where in my template class, but the compiler creates 2 different code-bases, if I remove the _C_Size in the template it becomes the same code-base. I’ve tried many constructions without any luck. Form a functional point of view they should be similar, it might be the C++ compiler way of identifying types that causes the problem.

I really appreciate some help on this topic.

Comment on Aliasing and how to control it by davidcrocker

davidcrocker — Tue, 01 Mar 2011 15:43:16 +0000

Hi, and thanks for your comment. One of the problems with invariants in C is knowing when they are supposed to hold, because they generally get broken while structures are being updated. Where an invariant involves 2 or more structs, what we generally do in eCv is declare a "valid" function instead of an invariant. For your example we would do something like the following:

ghost(bool valid2(hedge_t *he)
    returns(he->opposite != he);)
ghost(bool valid2(hedge_t *he1, hedge_t *he2)
    returns((he1->opposite == he2) =>
                       (he2->opposite == he1));)

and so on. Next we would declare a ghost function that returns true if all elements and pairs of elements in a collection of half edges obey these validity constraints. Finally we would refer to that ghost function in preconditions and postconditions of functions that manipulate half edges belonging to that collection. There are other approaches, for example Microsoft Research's Vcc tool requires you to wrap and unwrap objects explicitly to indicate when their invariants are expected to hold. We found that the overhead of this extra annotation wasn't necessary or justified when verifying typical safety-critical software (which typically doesn't use complex data structures); but it may be more suited to your example.

Comment on Verifying loops: proving termination by davidcrocker

davidcrocker — Tue, 01 Mar 2011 15:23:55 +0000

Hi Artyom, I can’t see any particular problem with verifying in eCv that the classic implementation of in-place quicksort terminates. Can you explain what disjointness constraints you were concerned about?

Comment on Verifying loops: proving termination by Artyom Shalkhakov

Artyom Shalkhakov — Tue, 01 Mar 2011 08:08:25 +0000

Hello,

I wonder if there is an example of verifying, say, that a quicksort on array of ints terminates. Some time ago I tried to do that in a programming language but was bitten by disjointness constraints on the input array (with more care I could’ve persuaded the typechecker that types are correct, but …).