Discussion :

[paterson]

Bonjour , je réalise sur un microcontroleur une multiplication

Code C++ :

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

1
2
3
4
5
6
unsigned int a,b,c; 
 
a=900;
b=90 ;
 
c=a*b;//c=81000= 0x1 3C68 >deviens> 0x3C68 = 15464

J'aimerais savoir s'il existe une fonction qui fonctionne sur tous les micro-contrôleurs pour détecter cette erreur.

Merci d'avance

[ternel]

non, ca s'appelle un integer overflow, et c'est inhérent au fait que les entiers ont une représentation finie.
Par contre, tu peux souvent savoir que tu va subir l'erreur

[Sve@r]

J'aimerais savoir s'il existe une fonction qui fonctionne sur tous les microcontroleur pour détecter cette erreur.

Bonjour

On peut tricher en redéfinissant sa propre multiplication qui intègrera un contrôle du résultat

Code c :

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
#include <stdio.h> 
#include <stdlib.h>
 
int mult(int x, int y, int *err)
{
	int res=x*y;
	if (err)
	{
		if (x) (*err)=(res / x) == y ?0 :1;
		else {
			if (y) (*err)=(res / y) == x ?0 :1;
			else (*err)=0;
		}
	}
 
	return res;
}
 
int main(int argc, char *argv[]) 
{ 
	int x, y, res;
	int err;
 
	x=10;
	y=20;
	res=mult(x, y, NULL);
	printf("%d * %d=%d\n", x, y, res);
 
	x=10;
	y=20;
	res=mult(x, y, &err);
	printf("%d * %d=%d (err=%d)\n", x, y, res, err);
 
	x=9000000;
	y=900000;
	res=mult(x, y, &err);
	printf("%d * %d=%d (err=%d)\n", x, y, res, err);
}

...

[foetus]

@Sve@r: N'y a-t-il pas un truc qui cloche avec ton code?

En plus, de la valeur de retour qui vaut false (0) si tout c'est bien passé.
Et aussi de dire que "tout" c'est bien passé (<- à ta façon) lorsque err est NULL.

Si x vaut 0, alors res vaut 0: pas la peine de tester la valeur de y dans ce cas.

[Vincent PETIT]

J'aimerais savoir s'il existe une fonction qui fonctionne sur tous les microcontroleur pour détecter cette erreur.

Tu veux détecter un overflow lors d'un calcul arithmétique ?
Bien sur que l'on peut, comment penses tu que l'on fais lorsqu'on bosse en assembleur ?

Dans ton micro, il y a forcément un registre qui t'indique si une opération arithmétique a débordée.

Sur le micro ATMEGA328P (Arduino UNO) c'est normalement dans le registre SREG
Sur le micro PIC18F4550 c'est le registre STATUS REGISTER
Sur le micro MSP430G2253 (LaunchPad) c'est le registre SR

Par contre, je n'arrive pas à comprendre pourquoi tu souhaites faire ça ? Ton micro est une calculette ?

[Bktero]

@Sve@r: N'y a-t-il pas un truc qui cloche avec ton code?

Si x vaut 0, alors res vaut 0: pas la peine de tester la valeur de y dans ce cas.

La structure de tests pourrait être plus claire peut-être. Dans le main, j'ai un doute sur l'affichage de err.

En plus, de la valeur de retour qui vaut false (0) si tout c'est bien passé.

Tu as déjà essayé de faire echo $? sous Unix pour connaitre la valeur de retour d'une commande ?

Et aussi de dire que "tout" c'est bien passé (<- à ta façon) lorsque err est NULL.

T'as déjà essayé de déréférencer NULL pour y écrire ton code d'erreur toi ????

[grim7reaper]

On peut tricher en redéfinissant sa propre multiplication qui intègrera un contrôle du résultat

Code c :

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
#include <stdio.h> 
#include <stdlib.h>
 
int mult(int x, int y, int *err)
{
	int res=x*y;
	if (err)
	{
		if (x) (*err)=(res / x) == y ?0 :1;
		else {
			if (y) (*err)=(res / y) == x ?0 :1;
			else (*err)=0;
		}
	}
 
	return res;
}

Ce code est buggué car il contient un UB (undefined behavior).
Tu utilises des entiers signés et l’overflow sur les entiers signés est un UB (sur les entiers non-signé, c'est défini par contre). Dès le moment où tu as fait la multiplication, c'est trop tard.

C'est comme faire du code de ce genre :

Code C :

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

1
2
3
4
5
6
7
8
9
static void __devexit agnx_pci_remove (struct pci_dev *pdev)
{
  struct ieee80211_hw *dev = pci_get_drvdata(pdev);
  struct agnx_priv *priv = dev->priv; 
 
  if (!dev) return;
 
  ... do stuff using dev ...
}

C’est buggué car tu as déjà déclenché ton UB avant le test et le compilateur peut virer ton test.

Les UB ça peut être source de bug très sioux, car ça peut dépendre des options d'optimisations, de ton compilateur voire même de la version de ton compilateur (j'ai déjà été confronté à une SEGFAULT qui ne se produisait qu'avec clang + optimisations, cf. ici pour ceux que ça intéressent).

Pour ceux qui veulent en savoir plus sur les UB, je vous conseille deux séries de trois articles :
La série de Chris Lattner :
- What Every C Programmer Should Know About Undefined Behavior #1/3
- What Every C Programmer Should Know About Undefined Behavior #2/3
- What Every C Programmer Should Know About Undefined Behavior #3/3
Et la série de John Regehr (qui a un très bon blog, je vous le recommande chaudement) :
- A Guide to Undefined Behavior in C and C++, Part 1
- A Guide to Undefined Behavior in C and C++, Part 2
- A Guide to Undefined Behavior in C and C++, Part 3


Pour en revenir au sujet (comment tester l’overflow) après cette digression sur les UB, il y a plusieurs façons qui dépendent de tes contraintes*:
- How Should You Write a Fast Integer Overflow Check?
- Catching Integer Overflows in C

Cela dit, si l‘on se limite aux entier non-signés (ce que l'auteur du sujet utilise dans son exemple), la situation est plus simple car l‘overflow est définie par le standard (wrap-around). Du coup, pour la détection on peut se contenter de faire quelque chose du genre (à tester, surtout sur les cas limites)*:

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
 
unsigned mul(unsigned x, unsigned y, int *err)
{
    unsigned res = x * y;
 
    if (err) {
        *err = (res < x || res < y);
    }
 
    return res;
}

[Médinoc]

Personnellement en non-signé, je ferais quand même une division pour vérifier, plutôt qu'un test d'infériorité.

[grim7reaper]

Personnellement en non-signé, je ferais quand même une division pour vérifier, plutôt qu'un test d'infériorité.

Oui, c'est peut-être plus fiable que le test d'infériorité (j'ai pas testé le comportement avec des valeurs limites).

[Sve@r]

En plus, de la valeur de retour qui vaut false (0) si tout c'est bien passé.

C'est une habitude venue du shell où l'état d'une commande vaut 0 quand la commande s'est bien passée. C'est d'ailleurs plutôt logique: quand quelque chose se passe bien, pas besoin d'expliciter (=> autant utiliser alors 0). En revanche, si quelque chose se passe mal, alors t'as toute la gamme des positifs disponibles pour indiquer en finesse le détail de ce qui a cloché (1=truc qui ne s'ouvre pas, 2=chose qui n'est pas alloué, 3=machin pas connecté, etc...).
Et c'est parfois aussi le cas en C (strcmp() qui vaut 0 quand c'est égal)...

Et aussi de dire que "tout" c'est bien passé (<- à ta façon) lorsque err est NULL.

Non t'as pas bien saisi le principe: si l'appelant veut un retour des erreurs éventuelles il passe alors l'adresse d'une variable destinée à stocker ce retour. En revanche s'il ne veut pas s'en préoccuper, alors il passe NULL et donc considèrera (par défaut) que l'opération se passe bien.

Si x vaut 0, alors res vaut 0: pas la peine de tester la valeur de y dans ce cas.

Exact - Fameux manque d'à propos à ce sujet. Mais c'était à 23h et j'étais pas mal crevé