par Julian Monypenny
Comment repérer les bogues potentiels dans des expressions arithmétiques, en écrivant des programmes "blindés"
Je ne me lasse pas des films La Panthère Rose de Blake Ewards. J'aime tout particulièrement
l'obsession qu'a l'inspecteur Clouseau de se perfectionner sans cesse dans les
arts martiaux. C'est dans ce but que son acolyte, Cato, l'attaque à l'improviste
au moment le plus inattendu. Clouseau estime que pour dominer la situation, il
faut apprendre à "s'attendre à l'inattendu".
Les programmeurs que nous sommes doivent aussi s'attendre à l'inattendu. Dans
l'article "Style RPG IV : pour écrire un code sain", NEWSMAGAZINE, septembre 2000,
nous avons vu comment écrire un code solide en nous concentrant sur le traitement
des erreurs renvoyées par les opérations d'I/O. Les erreurs d'I/O sont faciles
à piéger grâce aux indicateurs résultants ou aux fonctions intégrées comme %Error
et %Found. Mais certaines erreurs de programmation sont bien plus insidieuses
que celles d'I/O. Les erreurs les plus courantes rencontrées dans des programmes
RPG IV sont dues à des expressions arithmétiques associées à l'opération Eval.
Nous allons donc évaluer des expressions arithmétiques en décrivant les erreurs
auxquelles on peut s'attendre et en expliquant comment les contrôler fermement.
Certaines erreurs de programmation sont bien plus insidieuses que celles
d'I/O
Style RPG IV : même l’inattendu peut arriver !
On connaît la maxime, « Garde tes amis près de toi, tes ennemis encore plus près ». A première vue, l’opération Eval semble amicale aux yeux du programmeur RPG. On peut en effet effectuer des calculs de gestion très complexes, de façon lisible, en combinant la souplesse d’Eval aux noms symboliques intelligibles du RPG IV. On peut, par exemple, exprimer le pourcentage de profit sur une vente directement avec Eval, sous la forme
C Eval PrfPc = (RtlAmt – CstAmt) /
C RtlAmt * 100
Malheureusement, quatre types d’actions ennemies menacent ce calcul :
l’arrondi
la perte de précision décimale
la division par zéro
la troncature d’ordre supérieur (ou à gauche)
Chacun de ces quatre types d’action ennemie constitue un bogue potentiel et donc notre opération Eval n’est pas si inoffensive que cela. On se souvient que, dans l’article précédent, j’ai divisé les bogues de programmes en deux catégories : explosifs et radioactifs. Avec les premiers, un énorme bang est signalé par un message d’exception qui stoppe net le programme. En revanche, avec des bogues radioactifs, le programme se conclut normalement, mais c’est la sortie obtenue qui souffre de l’exposition au code. Eval prend en charge les bogues explosifs et radioactifs. Pour garantir la bonne fin de l’Eval le plus simple, voyons chaque type de bogue et comment le traiter.
Téléchargez cette ressource
Percer le brouillard des rançongiciels
Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- La performance de l’IA et l’analytique reposent sur des fondations de données solides
- AI Appreciation Day,16 juillet « cet email de 10 pages aurait pu se résumer en 3 points »
- L’informatique quantique perçue comme la menace de cybersécurité la plus critique
- Bâtir une entreprise AI-native : par où commencer
- La France à l’avant-garde de la conteneurisation et de l’IA générative
