Discussion :

[chrtophe]

Bonjour,

Je voulais comment détecter un overflow sur une opération sur des int.

Je ne code pas, c'est juste une interrogation.

[Sve@r]

Bonjour
Désolé on ne peut pas. (unsigned short)65535 + 1 donnera 0 sans que tu ne puisses détecter si c'est normal ou pas. Enfin le terme "normal" est mal utilisé car c'est en réalité tout à fait normal (le "1" qui se trouve sur le 33° bit n'est pas récupéré) mais tu ne peux pas détecter si la valeur officielle devait être 65536 ou 0.

[chrtophe]

Merci pour le retour.

C'était ce qu'il me semblait avoir compris, mais j’avais l'impression de comprendre de travers.

Surprenant qu'on ne puisse détecter un overflow, je trouve même ça problématique.

[Sve@r]

Surprenant qu'on ne puisse détecter un overflow, je trouve même ça problématique.

C'est tiré de la conception du C: son but clairement défini est d'aller le plus vite possible. Et pour cela il ne vérifie rien, absolument rien. Je peux écrire char *pt=(char*)123 puis aller voir printf("%d", *pt) je n'aurai aucun souci de compilation.
C'est effectivement problématique pour ceux qui sont habitués à travailler avec un langage rempli de garde-corps.

[foetus]

Surprenant qu'on ne puisse détecter un overflow, je trouve même ça problématique.

bof, c'est surtout à l'exécution que le problème intervient.
L'exemple de @Sve@r est assez simple, et n'est sûrement pas représentatif des "overflows".
Le compilateur peut faire la tâche mais pour combien de problèmes ? 2% ? 20% ? 50% ? 70% ? 92% ?

Et c'est l'histoire du vol 501 d'Ariane 5 (<- lien Wikipédia) "les valeurs trop élevées mesurées par les accéléromètres ont provoqué un dépassement de capacité"

[Sve@r]

L'exemple de @Sve@r est assez simple, et n'est sûrement pas représentatif des "overflows".

Le fait qu'un exemple soit simple est souvent une bonne chose, non ?
C'est vrai, il se voulait plutôt représentatif des erreurs d'adressage non détectées et qui provoquent un UB. Parce que pour l'overflow effectivement, sauf à "voir" que la valeur finale est plus petite que la valeur d'origine (on présume que celle-ci est censée croître dans l'opération) il n'y a pas d'erreur à l'exécution (ni même de UB).

Et c'est l'histoire du vol 501 d'Ariane 5 (<- lien Wikipédia) "les valeurs trop élevées mesurées par les accéléromètres ont provoqué un dépassement de capacité"

Un de mes profs d'info avait parlé de sinus négatif calculé en unsigned (légende urbaine issue du téléphone arabe probablement) et le lien wiki est plus précis. Ou alors il parlait d'un autre crash...

[dalfab]

Les languages C et C++ ne vérifient pas les dépassements de capacités des types fondamentaux. D'autres languages vont prévenir avec par exemple une exception. Mais est-ce vraiment mieux?
Le code peut difficilement "corriger" le problème et aboutit finalement à un arrêt du programme.
Si on prend le cas du vol 501 d'Ariane, il y aurait eu signalement immédiat de l'anomalie (au lieu d'une anomalie détectée indirectement) pour arriver finalement au même problème

Justement, je connais le problème de l'Ariane. A l'époque, ma société participait à la qualification de modules d'Ariane (pas celui incriminé ici). Et pour préciser ce que dit Wikipédia, l'évolution du matériel a bien été requalifiée. On a eu alors des précisions en particulier sur le contrôle calibration indiqué évidemment comme non actif pendant le vol. En fait les résultats n'étaient pas utilisés, mais ses erreurs, elles, continuaient de remonter.
Le principal problème est, selon moi, l'ambiguïté sur "le contrôle calibration est désactivé" (est-ce un retrait total, la non utilisation des résultats, les erreurs traitées même si l'utilisation est désactivée?)

Il y eu une cause additionnelle non citée dans l'article. La préparation a duré plus que prévu, et la température du comburant était à la limite supérieure, d'où une fluidité plus grande, d'où une poussée un peu supérieure à l'attendu. Peut-être que si on avait fait moins de pré-contrôles, on n'aurait pas eu le problème

[kick54]

Le fait qu'un exemple soit simple est souvent une bonne chose, non ?
C'est vrai, il se voulait plutôt représentatif des erreurs d'adressage non détectées et qui provoquent un UB. Parce que pour l'overflow effectivement, sauf à "voir" que la valeur finale est plus petite que la valeur d'origine (on présume que celle-ci est censée croître dans l'opération) il n'y a pas d'erreur à l'exécution (ni même de UB).


Un de mes profs d'info avait parlé de sinus négatif calculé en unsigned (légende urbaine issue du téléphone arabe probablement) et le lien wiki est plus précis. Ou alors il parlait d'un autre crash...

Bonjour,
Pareil, un prof citait l'exemple de bugs mémorables dont celui où le résultat de calcul d'un sinus devenait brutalement négatif au passage de l'équateur (la latitude changeant de signe), et le prof précisait que l'avion en pilotage automatique se mettait à voler sur le dos...
... De même je n'ai jamais su si c'était avéré ou une légende

[kick54]

Bonjour,

Je voulais comment détecter un overflow sur une opération sur des int.

Je ne code pas, c'est juste une interrogation.

Bonjour chrtophe,

Je pense qu'il faudrait toujours détecter ce genre d'erreur la qualité du logiciel ne peut qu'en être améliorée.

Je complète mon commentaire avec un premier exemple qui traite le débordement d'entier en utilisant :
l'option de compilation -ftrapv, et
l'interception du signal SIGABRT

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
 
/** err1.c **/
 
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <signal.h>
#include <stdint.h>
 
 
void h1(int signal)
{
	printf("Interception signal SIGABRT (%d)\n", SIGABRT);
	exit(1);
}
 
int main(){
 
	int a = INT32_MAX ;
 
	signal(SIGABRT,h1);
 
	printf("Taille int = %d\n\t a= %d\n\t a+1 = ...",sizeof(int), a);
	printf("%d\n", a+1);	
 
	return(0);
}
 
 
/********* Compilation et exécution (Cygwin - gcc version 11.4.0)
$ gcc -ftrapv  err1.c -o err1
$ ./err1
Taille int = 4
         a= 2147483647
         a+1 = ...Interception signal SIGABRT (6)
 
Compilation sans l'option -ftrapv
$ gcc  err1.c -o err1
$ ./err1
Taille int = 4
         a= 2147483647
         a+1 = ...-2147483648
 
*/

Pour d'autres cas d'erreur, comme la division par zéro, l'interception par signal() de SIGFPE peut aussi être utile ...
Bien que la division par zéro est de toute façon détectée et provoque l'interruption du programme,
le point où elle se produit, peut être plus difficile (ou pas ;-) à localiser sans l'interception du signal.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
 
/** err2.c **/
 
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <signal.h>
#include <stdint.h>
 
void h2(int signal)
{
	printf("Interception signal SIGFPE (%d)\n", SIGFPE);
	exit(2);
}
 
int main(){
 
	int a = INT32_MAX ;
	int b = 0 ;
 
	signal(SIGFPE,h2);
 
	printf("a / 0 = ...");			
	printf("%d\n",a/b);
 
	return(0) ;
}
 
/********* Compilation et exécution (Cygwin - gcc version 11.4.0)
$ gcc err2.c -o err2
$ ./err2
a / 0 = ...Interception signal SIGFPE (8)
 
 
$ gcc  err2.c -o err2
$ ./err2
Floating point exception
 
 
*/