Je risque être confronté au développement d'un soft avec contraintes de sécu
en C sur DSP.
J'ai trouvé des notes sur la programmation défensive etc et sur le
traitement des exceptions.
Existe-t-il un mécanisme analogue en C de traitement des erreurs et/ou
Exceptions pour dérouter mon application vers un "état" connu en cas
d'intervention d'une exception ?
Quels sont les meilleurs principes de programmation en ce qui concerne le
traitement des erreurs ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Leca
En chjtvq$39a$, lionel vigier va escriure:
Existe-t-il un mécanisme analogue en C de traitement des erreurs et/ou Exceptions pour dérouter mon application vers un "état" connu en cas d'intervention d'une exception ?
<setjmp.h>, setjmp(), longjmp().
Ce mécanisme C, bien que relativement efficace et largement implémenté (y compris en présence de thread etc.), n'a cependant pas la réputation d'être très solide. Il est en particulier assez facile qu'un pointeur errant ait écrasé ton jmp_buf (après tout, si tu es dans un traitant d'exception, c'est qu'il y a eu quelque chose d'imprévu...), et donc quand tu vas faire le longjmp() tu vas partir n'importe où et c'est le déroutement imprévu (SIGSEGV ou ACCESS VIOLATION).
Quels sont les meilleurs principes de programmation en ce qui concerne le traitement des erreurs ?
Quelques idées comme elles me viennent:
- Traiter les erreurs au plus tôt, pour éviter le GIGO (garbage in, garbage out).
- Traiter TOUTES les erreurs, y compris "ce qui ne peut pas arriver".
- Analyser précisement son problème, pour réduire le domaine de fonctionnement au strict minimum, ce qui permet de bons contrôle de domaine sur les valeurs des calculs intermédiaires; ainsi, quand cela dérive, tu peux détecter au plus tôt, bien avant que la fusée ne soit sortie de sa trajectoire... Et surtout, ne pas fonder ces analyses de domaine sur l'ensemble des possibles en sortie de la boîte noire précédente, mais aller jusqu'aux paramètres physiques sous-jacents.
- Tester les traitements d'erreur. Et retester. C'est fou le nombre de traitements d'erreur qui en fait ne sont pas opérationnels (parce que fondés sur une logique de l'application qui a évoluée sans que le traitement d'erreur soit mis à jour; en particulier, existance de mémoire allouée ou pas), mais cela n'est jamais détecté car le code en question n'est pas actif par défaut.
Antoine
En chjtvq$39a$1@news-reader2.wanadoo.fr, lionel vigier va escriure:
Existe-t-il un mécanisme analogue en C de traitement des erreurs et/ou
Exceptions pour dérouter mon application vers un "état" connu en cas
d'intervention d'une exception ?
<setjmp.h>, setjmp(), longjmp().
Ce mécanisme C, bien que relativement efficace et largement implémenté (y
compris en présence de thread etc.), n'a cependant pas la réputation d'être
très solide. Il est en particulier assez facile qu'un pointeur errant ait
écrasé ton jmp_buf (après tout, si tu es dans un traitant d'exception, c'est
qu'il y a eu quelque chose d'imprévu...), et donc quand tu vas faire le
longjmp() tu vas partir n'importe où et c'est le déroutement imprévu
(SIGSEGV ou ACCESS VIOLATION).
Quels sont les meilleurs principes de programmation en ce qui
concerne le traitement des erreurs ?
Quelques idées comme elles me viennent:
- Traiter les erreurs au plus tôt, pour éviter le GIGO (garbage in, garbage
out).
- Traiter TOUTES les erreurs, y compris "ce qui ne peut pas arriver".
- Analyser précisement son problème, pour réduire le domaine de
fonctionnement au strict minimum, ce qui permet de bons contrôle de domaine
sur les valeurs des calculs intermédiaires; ainsi, quand cela dérive, tu
peux détecter au plus tôt, bien avant que la fusée ne soit sortie de sa
trajectoire... Et surtout, ne pas fonder ces analyses de domaine sur
l'ensemble des possibles en sortie de la boîte noire précédente, mais aller
jusqu'aux paramètres physiques sous-jacents.
- Tester les traitements d'erreur. Et retester.
C'est fou le nombre de traitements d'erreur qui en fait ne sont pas
opérationnels (parce que fondés sur une logique de l'application qui a
évoluée sans que le traitement d'erreur soit mis à jour; en particulier,
existance de mémoire allouée ou pas), mais cela n'est jamais détecté car le
code en question n'est pas actif par défaut.
Existe-t-il un mécanisme analogue en C de traitement des erreurs et/ou Exceptions pour dérouter mon application vers un "état" connu en cas d'intervention d'une exception ?
<setjmp.h>, setjmp(), longjmp().
Ce mécanisme C, bien que relativement efficace et largement implémenté (y compris en présence de thread etc.), n'a cependant pas la réputation d'être très solide. Il est en particulier assez facile qu'un pointeur errant ait écrasé ton jmp_buf (après tout, si tu es dans un traitant d'exception, c'est qu'il y a eu quelque chose d'imprévu...), et donc quand tu vas faire le longjmp() tu vas partir n'importe où et c'est le déroutement imprévu (SIGSEGV ou ACCESS VIOLATION).
Quels sont les meilleurs principes de programmation en ce qui concerne le traitement des erreurs ?
Quelques idées comme elles me viennent:
- Traiter les erreurs au plus tôt, pour éviter le GIGO (garbage in, garbage out).
- Traiter TOUTES les erreurs, y compris "ce qui ne peut pas arriver".
- Analyser précisement son problème, pour réduire le domaine de fonctionnement au strict minimum, ce qui permet de bons contrôle de domaine sur les valeurs des calculs intermédiaires; ainsi, quand cela dérive, tu peux détecter au plus tôt, bien avant que la fusée ne soit sortie de sa trajectoire... Et surtout, ne pas fonder ces analyses de domaine sur l'ensemble des possibles en sortie de la boîte noire précédente, mais aller jusqu'aux paramètres physiques sous-jacents.
- Tester les traitements d'erreur. Et retester. C'est fou le nombre de traitements d'erreur qui en fait ne sont pas opérationnels (parce que fondés sur une logique de l'application qui a évoluée sans que le traitement d'erreur soit mis à jour; en particulier, existance de mémoire allouée ou pas), mais cela n'est jamais détecté car le code en question n'est pas actif par défaut.
