## Verifying pointer arithmetic

Today I’ll look at whether code that uses pointer arithmetic is any harder to verify than equivalent code that does not use pointer arithmetic.

Consider this function for copying an array (or part of an array) into another array (or part of another array):

voidarrayCopy(const int* src,int* dst, size_t num) { size_t i;for(i = 0; i < num; ++i) { dst[i] = src[i]; } }

## Run-time checks: Are they worth it?

One of the criticisms levelled against the use of C in safety-critical software is that the C language does not provide run-time checks automatically. For example, when indexing into an array, there is no check that the index is in bounds. Likewise, when doing integer arithmetic in C, there is no check for arithmetic overflow. Read more…

## Aliasing and how to control it

Today I’ll start by writing a simple function that determines the maximum and minimum of two integers. We want to return two values, and C doesn’t make that easy unless we declare a **struct **to hold them. So I’ll pass two pointers to where I want the results stored instead. Here goes:

#include"arc.h"voidminMax(inta,intb,out int*min,out int*max)post(*min <= a; *min <= b; *min == a || *min == b)post(*max >= a; *max >= b; *max == a || *max == b) { *min = a < b ? a : b; *max = a > b ? a : b; }

I’ve highlighted the ArC annotations in green. Read more…

## Verifying absence of integer overflow

One class of errors we need to guard against when writing critical software is arithmetic overflow. Before I go into detail, I invite you to consider the following program and decide what it prints:

#include<stdio.h>intmain(intargc,char*argv[]) {unsigned intx = 42;longy = -10; printf("%s\n", (x > y ? "Hello, normal world!" : "Hello, strange world!"));return0; }

## Specification with Ghost Functions

In my previous post I showed that the C expression sublanguage extended with quantified expressions (**forall **and **exists**) is insufficient to allow some specifications to be expressed. I presented this function (annotated with an incomplete specification) to average an array of data:

int16_t average(constint16_t *arrayreadings, size_t numReadings)pre(readings.lwb == 0; readings.lim == numReadings)pre(numReadings != 0)post(result== ?/* sum of elements of readings *//numReadings) {intsum = 0; size_t i;for(i = 0; i < numReadings; ++i)keep(i <= numReadings)keep(sum == ?/* sum of first i elements of readings */)decrease(numReadings - i) { sum += readings[i]; }return(int16_t)(sum/numReadings); }

## Expressing the Inexpressible

When writing preconditions, postconditions and other specifications for C programs, sometimes we need to write expressions that can’t be expressed in plain C. That’s why formal verification systems based on annotated programming languages almost always augment the expression sublanguage with **forall **and **exists **expressions. In previous posts, I’ve introduced ArC’s implementations of these. For example, the following expression yields **true **if all elements of the array *arr *are between 0 and 100 inclusive:

forallindinarr.indices :- arr[ind] >= 0 && arr[ind] <= 100

Here, *ind *is declared as a bound variable that ranges over the values in the expression that follows the keyword **in**, which in this case is all the indices into *arr*. Read more…

## Verifying a binary search, part 2

In my last entry I showed how to use a correct-by-construction approach to develop a binary search function. We got as far as specifying the function and the loop, but we left the loop body undefined. The function declaration looked like this: Read more…