regles de codage stricte ?

Bonjour,

je ne sais pas trop sur quel forum poser la question alors ce sera ici ;)

Suite au bug tres connu d'un overflow sur le lanceur Ariane 5 en 1996 (si mes souvenirs sont bons) qui a provoque sa destruction, j'ai entendu dire que ceci a eu pour consequence d'engendrer de nouvelles regles de codage beaucoup plus strictes qu'auparavant chez le contructeur.

Est-ce que quelqu'un connaitrait ces regles et si oui, ou peut-on les consulter? Il s'agit de simple couriosite. Je ne travaille pas sur des logiciels critiques mais quand je dois debuguer et chasser des pointeurs qui pointent sur NULL, je me dis qu'on devrait imposer des regles strictes pour tous les developpeurs... :bug:

Merci d'avance pour vos reponses

en C++? ne fait pas de pointeurs quand tu n'en as pas besoin

Citation:

---

Envoyé par nikko34

en C++? ne fait pas de pointeurs quand tu n'en as pas besoin

---

Mon probleme est que je debug du code ecrit par d'autres qui ne sont pas tres rigoureux. Pour ma defense, je suis du genre a mettre des assertions partout et a verifier les pointeurs non null avant d'y acceder, car moi je sais que j'insere des bugs :)

Je ne sais pas à quoi tu fais allusion, mais à ce que j'ai compris (je n'ai pas d'infos de première main, uniquement de seconde ou pire) de cette explosion, il n'y avait pas vraiment de problème de codage. Une fonction a sorti une valeur qui n'était pas dans la zone admissible, le code qui était bien fait et testait ces valeurs a donc déclenché la procédure de sécurité, qui a déterminé selon les specs qu'il était plus sage de s'auto-détruire.

Le problème en l'occurrence serait un problème de management, qui pour gagner du temps a demandé qu'un bout de code d'Ariane 4 soit réutilisé sans que l'on passe par une phase complète de validation de ce code, phase qui aurait modifié la zone admissible pour la valeur.

Comme Loic, je ne me souviens pas de probleme de codage. Des problemes de reutilisation sans revalidation et sans test, des problemes de conception (pourquoi laisser un composant qui n'est plus utile a ce moment la et n'aura plus d'utilite demander l'auto-destruction de la fusee), oui. Mais rien adressable par des regles de codage.

J'ai entendu dire que l'allocation dynamique était interdite pour tout ce qui touche l'embarqué dans les avions (je parle ici de C). Ça me parait étrange, je ne sais pas si c'est vrai.

Ariane utilise de l'analyse statique pour prouver que son code est correct.
Pour ce qui est du code d'Ariane, il est (ou du moins était) en Ada il me semble.

il est en ADA car c'est le seul compilateur qui est certifié produire le meme code que ce que l'utilisateur a demandé (pas de bug de codegen donc).
je ne pense pas qu'il existe d'autres compilateurs certifiés.

En langage C (ici on est sur le forum C++), il y a les rêgles Misra.

Sinon, il y a des analyseurs statiques et dynamiques.

Hé! hé! _vince_, je pense que tu n'as pas envie de jouer avec les règles de codages utilisées pour du soft embarqué dans les fusées:

They Write the Right Stuff

Plutôt laborieux, et comme le dit l'article, ce sont des règles pour la production de "logiciels qui contrôlent 4 milliards de dollars d'équipement, la vie d'une demi-douzaine de femmes et d'hommes, et les rêves d'une nation". Si ton appli fait du traitement d'images, ce n'est peut-être pas la peine de pousser aussi loin!

titoine1978, l'un des problèmes de l'allocation dynamique, c'est que ce n'est pas une opération temps-réel: tu ne sais pas a priori combien de temps peut prendre une demande d'allocation dynamique. Pour certains calculateurs embarqués, c'est inacceptable (s'ils doivent par exemple réagir en moins de 5ms à une condition d'erreur). C'est d'ailleurs pour cela que l'allocation dynamique est généralement bannie des moteurs temps-réel des applications audio aussi.

Carl