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

[LittleWhite]

Bonjour,

Par rapport à la question initiale, n'y a t-il pas un moyen avec les registres CPU (donc en assembleur ?). De mémoire, je pensais que la CPU allait mettre un flag à 1, en cas d'overflow.

[unanonyme]

https://wiki.sei.cmu.edu/confluence/...lt+in+overflow

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <limits.h>
 
void f(signed int si_a, signed int si_b) {
  signed int sum;
  if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
      ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
    /* Handle error */
  } else {
    sum = si_a + si_b;
  }
  /* ... */
}

https://gcc.gnu.org/onlinedocs/gcc/I...-Builtins.html

Code :

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

The compiler will attempt to use hardware instructions to implement these built-in functions where possible, like conditional jump on overflow after addition, conditional jump on carry etc.

non ?

[edgarjacobs]

Par rapport à la question initiale, n'y a t-il pas un moyen avec les registres CPU (donc en assembleur ?). De mémoire, je pensais que la CPU allait mettre un flag à 1, en cas d'overflow.

Je me suis posé la même question, il y a un bit dans un registre de la CPU qui est positionné en cas de dépassement, c'est l'overflow flag. Mais je ne sais pas si c'est pertinent dans cette discussion.

[Sve@r]

Mais je ne sais pas si c'est pertinent dans cette discussion.

Uniquement si on peut le récupérer en C...

[Christophe]

Uniquement si on peut le récupérer en C

Apparemment des fonctions internes à gcc présentes dans le lien d'unanonyme permettent de gérer l'overflow, mais je pense que ce n'est pas standard.

[dalfab]

Apparemment des fonctions internes à gcc présentes dans le lien d'unanonyme permettent de gérer l'overflow, mais je pense que ce n'est pas standard.

Ca n'est pas standard, je pense que c'est parce que ça nécessite d'utiliser les bits spécifiques à chaque processeur (carry et overflow) et que certains processeur pouvaient ne pas avoir. C'est faisable sans, mais lourd pour la multiplication.

Mais la plupart des compilateurs ont bien implémentés des fonctions intrinsèques pour cela.
Et le C++ semble avoir décidé que cette contrainte n'existe plus et fournit depuis C++26 : std::add_sat() std::sub_sat() std::mul_sat() std::div_sat() et std::saturate_cast<>(), ça devrait vraisemblablement aussi évoluer en C.

[Bousk]

Pour une opération d'addition que tu sais peux overflow, tu peux manuellement la prévenir - dans une certaine mesure.
Au lieu d'ajouter A + B puis vérifier si ça a dépassé, tu vérifies d'abord que MAX - A > B

[dalfab]

Pour une opération d'addition que tu sais peux overflow, tu peux manuellement la prévenir - dans une certaine mesure.
Au lieu d'ajouter A + B puis vérifier si ça a dépassé, tu vérifies d'abord que MAX - A > B

Pour les entiers non signés.

Pour les signés, il faut 2 tests.

[Guesset]

Bonjour,

La plupart des langages compilés permettent d'inclure des instructions assembleurs et les CPU ont toutes une collections de flags qui se positionnent à la moindre opération classique (entendre pas SIMD). C'est donc possible.

Mais ce n'est pas nécessairement souhaitable. Par exemple, si on doit vérifier que la différence entre 2 unsigned, Tnow - Tstart, reste en deçà d'une valeur dT, il est intéressant de pouvoir écrire if(Tnow - Tstart < dT) sans se préoccuper d'un overflow (il faut quand même que ce test soit réitéré avec une fréquence compatible avec la taille des unsigned utilisés).

Les options saturate ne corrigent pas le problème d'overflow mais le transforment : max + 1 = 0 devient max + 1 = max. En général pour l'implémenter à l'économie on utilise les instructions SIMD qui prévoient ce type d'opérations (ainsi qu'un certains nombre d'autres intéressantes, la plupart également induites par l'absence de tests intégrés difficiles à implémenter sur des vecteurs).

Salutations

[Médinoc]

Le pire, c'est que pour des entiers signés, l'overflow est un comportement indéfini, tu ne peux donc même pas tester après coup le résultat: Si la branche actuelle du code contient un calcul qui fait une overflow, tu as déjà perdu, game over.

Heureusement, ce n'est pas le cas des entiers non-signés, donc dans certains cas tu peux faire des tests, du genre:

Code C :

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

1
2
3
4
5
6
7
8
9
unsigned int multiplier(unsigned int a, unsigned int b)
{
	unsigned int res = a*b;
	if(res/a != b || res/b != a)
	{
		//Oups!
	}
	return res;
}

Malheureusement ceci est impossible avec des entiers signés, et je ne vois pas trop comment tester qu'une opération ne va pas causer d'overflow dans le cas de la multiplication.
Diviser INT_MAX par la valeur absolue de chaque opérande et comparer à l'autre? (en supposant qu'aucune opérande ne peut valoir INT_MIN, qui n'a pas de valeur absolue -- d'un autre côté une multiplication de INT_MIN par n'importe quelle valeur autre que 0 ou 1 est garantie causer une overflow)

[Guesset]

Bonjour,

La multiplication doit avoir un format d'accueil deux fois plus longs que les opérandes. Même en 32 bits le résultat d'une multiplication était déjà sur 64 bits (edx:eax) ce qui évite sur les signés (et les non signé) tous les dépassements y compris pour le -2³¹ qu'il convient d'éviter pour d'autres raisons (relative indétermination -imin = imin par exemple).

Code :

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

imul  edx  = edx*eax résultat dans edx:eax

Le C est assez permissif pour permettre d'écrire un truc comme une multiplication de 2 entiers de 64 bits à ranger dans un octet. La multiplication se fera bien dans les règles de l'art en étendant les 64 bits à 128 bits par concaténation des registres rdx et rax donc sans risque d'overflow mais le casting sauvage qui s'en suivra fera une troncature classique mais désastreuse sans remord ni overflow.

En résumé si on veut mettre les deux pieds dans le même soulier, il y a intérêt à changer de pointure

Salutations

[Kannagi]

Les CPU ont toutes une collections de flags qui se positionnent à la moindre opération classique. C'est donc possible.

Ben en fait non ^^
Par exemple RISC-V n'a pas de register flag.
(Je crois que le MIPS aussi mais pas sur).

Le soucis du flag register sur les processeurs moderne, c'est qu'ils empêchent certaine optimisation (où plutôt les rend horriblement compliqué), du coup les réduire à certaine instruction (cmp) ou les virer comme le fait RISC-V rend le design du processeur plus simple et plus facilement optimisable.
Donc il est probable que dans l'avenir ce genre de flag register disparaisse sur les nouvelles conceptions d'ISA.

[Christophe]

Et comment tu fais pour vérifier une retenue ? un dépassement ?