Discussion :

[Christophe]

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.

[Christophe]

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
 
 
*/