Modèles concrets de la mémoire

Nous avons utilisé dans l’introduction le concept de cellule mémoire. Cette notion peut être interprétée de différentes manières. Cette interprétation dépend du langage d’entrée de l’analyse. Aussi allons nous préciser l’idée générale que l’on cherche à capturer. Il s’agit de se convaincre qu’il est possible d’avoir un cadre général pour l’analyse des structures de données qui dépend peu du langage d’entrée. On donnera à la fin de cette section deux exemples d’interprétations de la notion de cellule.

En d’autres termes, cette section doit permettre la construction de modèles concrets de mé-moire [SJR10] adaptés aux différents langages de programmation. On ne s’intéresse pas encore à l’abstraction de ces modèles qui en seront une représentation approchée, finie et concise. On cherche à avoir des modèles capables de décrire de manière exhaustive l’état d’un programme.

De manière informelle, unecellulemémoire peut être considérée comme l’emplacement en mémoire d’une variable locale, globale, d’une cellule de tableau, d’un champ de structure de données, etc. On ne donnera pas ici de définition plus précise : d’un langage de programmation à un autre on aura une compréhension différente du concept.

Classiquement, en interprétation abstraite, les accès aux variables ne sont pas ambigus. Une fois résolus les problèmes de portée des variables, on sait exactement quelle variable est accédée par quelle expression. À l’inverse, les accès aux cellules ne peuvent être résolus statiquement. Une déréférenciation de pointeur ou un accès à un tableau peut être calculé à l’exécution. En cela, la cellule est donc une généralisation de la variable classique.

Nous ne pousserons pas plus loin la généralisation. En particulier, nous allons imposer une restriction. Les cellules doivent être atomique. Chaque écriture en mémoire doit modifier une cellule et une seule, dans sa totalité. Il ne doit pas être possible qu’une écriture modifie partiel-lement une cellule ou qu’elle altère du même coup une autre cellule.

C’est une propriété qui n’est pas nécessairement garantie dans l’exécution des programmes, notamment ceux en langage C non-standard : le programmeur peut par manipulation de pointeur et de types accéder à des fractions de cellules.

Cette restriction peut s’avérer problématique, bien qu’il soit courant de considérer que sa violation est ou bien une mauvaise pratique de programmation ou bien une erreur. Si le pas à franchir pour supprimer cette contrainte ne semble pas insurmontable, il introduirait néanmoins une complexité supplémentaire notable.

L’état d’un programme peut être décrit par la donnée des valeurs stockées dans chacune des cellules mémoire. Autrement dit, c’est une fonction de l’ensemble des cellules vers l’ensemble des valeurs possibles, ce que nous avons utilisé dans l’introduction.

Il est naturel de supposer que l’ensemble de cellules considéré varie durant l’exécution du programme. Lorsqu’on exécute une fonction, on ajoute les variables locales à cet ensemble de cellules, puis on les retire à la sortie. De la même manière, une allocation dynamique ajoutera les cellules nouvellement allouées, tandis qu’une désallocation les retirera.

Pour fixer les choses, considérons que toutes les cellules déjà allouées ou qui seront allouées dans l’avenir appartiennent à un ensemble universel, infini de cellules que nous noterons _C. C’est un stock de cellules dans lequel le programme va se servir chaque fois qu’il a besoin de nouvelles cellules. Le domaine des états est un sous-ensemble de _Cet les états sont donc des fonctions partielles. Nous noterons Σl’ensemble des états concrets, fonctions partielles de_C vers l’ensemble des valeurs_V:

Σ =CdV

Notons que pour un langage à pointeurs ou à références, il sera commode que l’ensemble des valeurs contienne l’ensemble des cellules.

Ceci nous donne un contexte général qui doit permettre d’analyser des programmes écrits dans la plupart des langages de programmation. Il doit y avoir en fait un travail à effectuer en amont de l’analyse statique pour adapter la sémantique du langage de programmation. Ceci afin que les lectures et écritures de données ne soient décrites qu’en terme d’accès aux cellules.

En général, la sémantique des langages s’appuiera sur la définition d’opérateursC

exp

(σ) et E

exp

(σ) permettant d’évaluer dans l’état σ ∈ Σl’expressionexp respectivement en une cellule et en sa valeur. Ainsi l’affectation

destexp ← srcexp

modifierait un étatσen l’état

σ0:s7→ E srcexp (σ) sis=C destexp (σ) σ(s) sinon

Exemple 2(Modèle mémoire simplifié pour un langage à tableaux).

Il est souvent utile d’avoir un langage réduit et simplifié pour expérimenter des analyses. Imagi-nons un langage dans lequel les tableaux sont des objets du premier ordre. On aurait deux types d’identificateurs : un ensemble d’identificateurs de variables scalairesS et un ensemble d’iden-tificateurs de tableaux unidimensionnelsT. Voici à quoi pourrait ressembler un programme dans ce langage :

array A

s c a l a r i , x = 0 for i = 1 to n

A[ i ] = x

Pour décrire la sémantique du programme en terme de cellules il faut décrire ce qui s’appelle classiquement un environnement : il faut associer une cellule à chaque identificateur de variable scalaire et une liste de cellules à chaque identificateur de tableau. C’est à dire une fonction

ρ: (S →_C)∪(T →(_N^∗→_C)) vérifiant pour toutx,y∈ Set toutA,B∈T

• x_,y⇒ρ(x),ρ(y) • ρ(x)<ρ(A)(_N^∗)

• A_, B⇒ρ(A)(_N^∗)∩ρ(B)(_N^∗)=∅ • i_, j⇒ρ(A)(i),ρ(A)(j)

ou autrement dit que chaque variable et chaque couple formé d’un tableau et d’un indice décrit une cellule distincte.

On peut ici confondrexetρ(x) etAetρ(A) et écrireA(i) au lieu deρ(A)(i). On aurait pour ce programme

S={i,x} ∪ {A(1),A(2), . . .}

Exemple 3(Modèle mémoire concret pour le langage C).

Afin de décrire toute une sémantique du langage C (ce que nous ne ferons pas) il est nécessaire que le modèle mémoire reflète la vision à bas niveau du langage. On peut construire_Ccomme un stock de variables des différents segments : des cellulesg₁,g₂, . . .pour les variables globales,

p₁,p₂, . . . pour la pile ett₁,t₂, . . . pour le tas.

Supposons que nous devions analyser le programme suivant.

#include <s t d l i b . h>

int main(int argc , char _{*argv [ ] )} {

unsigned int i , n = a t o i ( argv [ 1 ] ) ; int_{** A}= _{malloc (n*}sizeof(int_{* ) ) ;} for ( i = 0 ; i < n ; i++)

{

A[ i ] = _{malloc (n*}sizeof(int) ) ; }

}

Ce programme alloue dynamiquement un tableau à deux dimension de taillen×n oùnest un paramètre entré par l’utilisateur en ligne de commande. Le tableauApeut être arbitrairement grand.

Il y a 5 variables sur la pile :argc, argv, i, n etA. On peut leur attribuer les cellules p₁ à

p₅respectivement, sans problème particulier. Pour des programmes plus compliqués, il faudrait certainement considérer un pointeur de pile qui serait lui même une cellule.

Chaque utilisation de la fonctionmallocpermet d’accéder à un nouvel ensemble de cellules. Il est probablement plus pertinent de considérer que malloc est une construction de haut niveau et de lui donner une sémantique. Nous pouvons lui faire réserver n’importe quelle plage des cellules

t_ı, . . . ,t_ı+ disponible. Les cellules disponibles sont celles qui ne sont pas dans le domaine de définition de l’état concret tandis quemallocétend le domaine de définition de ce même état pour y ajouter les nouvelles cellules.

La variableAest un pointeur. On modélise ce pointeur en donnant à la cellule deAun contenu qui est lui même une cellule : la cellule pointée.mallocretourne la première cellule de la plage allouée qui est ensuite affectée àA. En terme d’opérateurs sémantiques, cela donne

C[∗A] (σ)=E[A] (σ) E[&A] (σ)=C[A] (σ)

Enfin, pour l’arithmétique de pointeur ou l’indexation, on peut utiliser l’indice des cellules allouées. Ainsi on aura

E[A] (σ)=t_ı ⇒ E[A+i] (σ)=C[A[i]] (σ)=t_ı+E[i](σ)

Avec ces choix, le premier appel àmallocva allouer les cellulest₁, . . . ,t_ où = E[n] (σ). Puis le second allouera les cellulest_+1, . . . ,t₂×, et ainsi de suite. Ainsi à la fin du programme on pourra décrire l’ensemble des étatsσatteignables

                                       σ:                                        p₃ 7→  p₄ 7→  p₅ 7→t₁ t₁ 7→t_+1 t₂ 7→t_2×+1 · · · t_ 7→t_×+1 ∈_N, σ∈ {s₁, . . . ,s₅} ∪ {h₁, . . . ,h_×(+1)}                                       

Remarque(Mémoire non initialisée).

Il n’est pas nécessaire d’introduire dans l’ensemble _V des valeurs possibles une valeur spé-ciale exprimant qu’une cellule n’a jamais été initialisée. Lorsqu’une cellule n’est pas initialisée, elle peut avoir n’importe quelle valeur : l’ensemble des états atteignables permettra d’énumé-rer toutes les combinaisons possibles de toutes les valeurs possibles pour chaque cellule non initialisée.