Utilisation des adresses d’espace en toute sécurité

Ces occasions se présentent souvent dans un corps de procédure. Par exemple, le traducteur peut déterminer facilement qu’une procédure accède en toute sécurité à ses propres variables locales. La difficulté surgit quand des pointeurs d’espace sont passés d’une procédure à une autre. Le plus souvent, une procédure peut être appelée pratiquement de n’importe où, et donc il est difficile de prouver quoi que ce soit à propos d’un pointeur généré par l’appelant d’une procédure.

Le traducteur peut en savoir plus sur ces arguments de procédure, par deux méthodes. L’une consiste à demander au programmeur des renseignements complémentaires sur la façon dont la procédure est appelée. L’autre, à analyser des programmes entiers et des programmes de service, pour obtenir les mêmes informations. Nous appellerons ces deux méthodes #pragma argopt et ARGOPT(*YES), respectivement.
La méthode #pragma argopt est réservée aux langages ILE C ou C++. Ils supportent la structure #pragma, qui permet de les utiliser de manière spécifique pour fournir des indices au compilateur. IBM offre la structure #pragma argopt à l’appui de l’optimisation d’arguments.

#pragma argopt est simple à utiliser. Supposons une procédure nommée foo() qui reçoit des pointeurs d’espace comme arguments ou qui renvoie des pointeurs d’espace au terme de l’opération. Vous pouvez ajouter la ligne suivante juste avant la définition de la procédure :

#pragma argopt foo

Vous devez ajouter la même ligne avant toute instruction qui appelle la procédure foo() en un point quelconque du programme (dans le même module ou dans un autre). Cela ordonne au traducteur de passer des adresses d’espace dans les appelants et de s’attendre à des adresses d’espace dans foo().

(((IMG7159)))
Figure 1.

La figure 1 ci-dessus montre une application constituée de deux modules nommés M et N. Le module M contient une procédure S qui s’attend à un paramètre pointeur d’espace et renvoie un résultat pointeur d’espace. Le module N contient une procédure P qui appelle S. L’exemple montre le placement des directives #pragma argopt pour s’assurer que les adresses d’espace sont passés, pas les pointeurs d’espace.

En tant que programmeur, vous donnez au traducteur des informations qu’il ne peut pas trouver lui-même. Tout simplement, vous dites : “Ces emplacements sont les seuls dans lesquels foo() est appelé, donc on peut s’attendre à des adresses d’espace.” Le traducteur peut ensuite vérifier à chaque site d’appel que l’argument passé est un pointeur d’espace valide. Puis le traducteur peut convertir le pointeur d’espace en une adresse d’espace.

Mais supposons que vous commettiez une erreur. Que se passe-t-il si vous n’identifiez pas correctement tous les appelants de foo() ? Dans ce cas, un appelant passerait un pointeur d’espace, bien que foo() s’attende à une adresse d’espace. Il en résulte une disparité.

Heureusement, ce n’est pas un problème. En cas d’incohérence dans un même module, le traducteur marque cela comme une erreur. S’il y a incohérence entre des modules, vous la découvrirez quand vous essaierez de lier les modules dans un programme ou dans un programme de service. Dans les deux cas, un message d’erreur vous demandera d’effectuer une correction.

#pragma argopt présente deux inconvénients. Premièrement, on l’a vu, cette option est réservée aux programmeurs C et C++. Deuxièmement, le code source doit être modifié pour tirer profit de l’optimisation d’arguments. Mais elle présente aussi des avantages. Vous pouvez utiliser #pragma sur des appels de procédures indirects (des appels passant par un pointeur de procédure). De plus, argopt est présente sur toutes les releases IBM i prises en charge. Vous verrez que ARGOPT(*YES) ne bénéficie pas de ces avantages.