Discussion :

[Luc Hermitte]

Bonjour,

Je fais une petit pub honteuse pour une présentation que je vais donner samedi 16 février à 11h dans les locaux du Centre Culturel Bellegarde à Toulouse.

Tour d'horizon des comportements non définis

Les comportements non définis - ou undefined behavior (UB) - sont nombreux en C et en C++. Nimbés d'une aura de mystère, ils sont le Père Fouettard qui sanctionne et scandalise les vilains petits développeurs. Personne ne les aime!

Comment un langage moderne peut-il faire de tels choix?!

Luc Hermitte nous expliquera ce que sont les «UB», pourquoi ils existent, quels avantages ils offrent, les problèmes qu'ils soulèvent et ce que l'on peut faire pour s'en prémunir.

Je vais essentiellement faire une synthèse rapide des présentations et articles de John Regehr et de bien d'autres sur le sujet des UB.

La question m'avait été posée dans le passé, a priori il n'y aura pas d'enregistrement (contrairement à la présentation que j'ai donnée au Capitole du Libre cette année au sujet de 2 règles qualité en C++).
Je mettrais les slides sur mon blog quand je les aurai finies ^^'

[koala01]

Salut,

Dommage que Toulouse soit si loin de chez moi, j'y aurais volontiers assisté

[Pyramidev]

Salut,

Certains comportements indéfinis du C++ sont entièrement justifiés et permettent de booster les performances, par exemple quand il n'y a pas de contrôle au runtime sur les integer overflow.
Par contre, d'autres comportements indéterminés du C++ auraient été des erreurs de compilation avec une conception plus moderne. Par exemple, quand on peut lire des variables non initialisées, c'est à cause du manque de contrôles du compilateur.

Pour illustrer mon propos, voici un code basique en Rust que l'on peut compiler sur https://play.rust-lang.org/ :

Code Rust :

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

1
2
3
4
5
6
7
8
9
fn main() {
	let var: i32;
	if true {
		var = 4;
	} else {
		var = 2;
	}
	println!("var == {}", var);
}

Ici, var n'est pas déclarée comme explicitement muable, donc elle est constante, mais sa durée de vie ne commence qu'à partir du moment où elle est initialisée.

En effet, si on écrit ceci :

Code Rust :

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

1
2
3
4
5
6
7
8
9
10
fn main() {
	let var: i32;
	if true {
		var = 4;
	} else {
		println!("var == {}", var);
		var = 2;
	}
	println!("var == {}", var);
}

alors on a une jolie erreur de compilation :

Code :

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

1
2
3
4
5
error[E0381]: borrow of possibly uninitialized variable: `var`
 --> src/main.rs:6:25
  |
6 |         println!("var == {}", var);
  |                               ^^^ use of possibly uninitialized `var`

Et si on commente le contenu du else :

Code Rust :

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

1
2
3
4
5
6
7
8
9
fn main() {
	let var: i32;
	if true {
		var = 4;
	} else {
//		var = 2;
	}
	println!("var == {}", var);
}

alors on a aussi une erreur de compilation :

Code :

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

1
2
3
4
5
error[E0381]: borrow of possibly uninitialized variable: `var`
 --> src/main.rs:8:24
  |
8 |     println!("var == {}", var);
  |                           ^^^ use of possibly uninitialized `var`

[Luc Hermitte]

Il est clair qu'un certain nombre devrait devenir des erreurs de compilation. Genre les returns oubliés.
Sauf que la priorité est à la rétro-compatibilité sur les codes incorrects. Je croise parfois des réticences à monter de version car de nouveaux warnings pourraient apparaître... Car sa fait du boulot à devoir valider des choses qui pourtant semblent fonctionner correctement.

[wolinn]

Je me suis fais une petite frayeur avec ça il y a quelques années en changeant de compilateur, passant de MSVC 2008 à g++.
Un "return" manquant dans une fonction, et MSVC passait dessus sans broncher, même pas un warning. Et comme la fonction était censée retourner un booléen, n'importe quoi non nul se trouvant sur la pile était converti en "true", une valeur licite et même censée être la plus courante pour cette fonction, ce qui explique que l'erreur soit passée inaperçue à l'exécution plusieurs années.
Il n'y avait qu'une seule erreur de ce type dans des centaines de milliers de lignes de code, mais j'ai passé ensuite des semaines à tout relire en me demandant quels types d'erreurs même g++ pouvait laisser passer, même en réglant des options d'alerte à la sensibilité maximale.
Mais je pensais que c'était un vrai bug de MSVC plutôt qu'un comportement indéfini accepté par la norme.
Il ne parait pas y avoir tant de situations où une telle omission est licite (une fonction dont on ne peut sortir que par une exception ? ce serait un peu bizarre, et encore plus de déclarer un type de retour).

[Pyramidev]

Il ne parait pas y avoir tant de situations où une telle omission est licite (une fonction dont on ne peut sortir que par une exception ? ce serait un peu bizarre, et encore plus de déclarer un type de retour).

Dans le cas où une fonction (appelons-là foo) a un type de retour autre que void mais que, dans son code, l'un des embranchements appelle une fonction (appelons-là bar) qui lance toujours une exception, alors c'est normal qu'il n'y ait pas d'instruction return en dessous de l'appel de bar.
Pour que le compilateur sache que ce n'est pas un oubli dans le code de foo, il faut annoter la fonction bar avec l'attribut [[noreturn]], mais ce dernier n'est disponible que depuis C++11.

[koala01]

Il ne parait pas y avoir tant de situations où une telle omission est licite (une fonction dont on ne peut sortir que par une exception ? ce serait un peu bizarre, et encore plus de déclarer un type de retour).

Sauf erreur de ma part, il n'y a que la fonction main, qui, bien que devant normalement renvoyer un entier, peut ne pas contenir le return 0; final.

[Bktero]

Pour que le compilateur sache que ce n'est pas un oubli dans le code de foo, il faut annoter la fonction bar avec l'attribut [[noreturn]], mais ce dernier n'est disponible que depuis C++11.

Dans ton lien, il est clairement dit que [[noreturn]] sert à indiquer qu'une fonction ne retourne jamais. Sauf à cause d'une exception. Elle ne sert donc pas à autoriser à omettre des instructions "return".

Typiquement, [[noreturn]] sert à indiquer une fonction qui fait une boucle infinie.

Voici un code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
void throwException() {
	throw "bim!";
}
 
[[noreturn]]
int half(int value) {
	if (value == 0) {
		throwException();
	} else {
		return value / 2;
	}
}

Il génère 2 warnings :

warning: function declared 'noreturn' has a 'return' statement
warning: 'noreturn' function does return

Sans le [[noreturn]], il en génère un seul :

warning: control reaches end of non-void function [-Wreturn-type]

[Pyramidev]

Tu as lu trop vite mon message, Bktero.
Voici un exemple plus explicite dans lequel je renomme bar en lancerException :

Code :

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

1
2
3
4
5
6
7
8
9
10
[[noreturn]] void lancerException();
 
TypeRetour foo(TypeParametre parametre) {
	if(condition)
		return quelqueChose();
	if(autreCondition)
		return autreChose();
	lancerException();
	// pas de return ici
}

[Bktero]

C'est carrément plus clair avec du code ! On est en phase du coup

[Médinoc]

Ce qui me scandalise n'est pas tant les comportements indéfinis eux-mêmes, que la clause que je mets ici en gras:

A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input. However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).

C'est la clause qui autorise explicitement les "time-traveling undefined behavior", ruinant les tentatives de déboguer le programme.

[Luc Hermitte]

Time travelling ou pas, ça ne changerait rien car à un moment donné ce qui sera exécuté ne correspondra pas. Au mieux avec le débugueur on va arriver jusqu'au point où ça déconne sauf que... on sait déjà très bien que le compilo peut réorganiser comme il l'entend une séquence d'instructions tant que cela produit quelque chose d'observable qui soit conforme à ce qui est décrit (cf la somme des n premiers entiers où boucle et récursion peuvent être réduits en n(n+1)/2; ou cf le fait que l'ordre des traitements change avec un -O3, etc)

Par contre on a besoin d'outillage pour détecter un max de contrats rompus, de préférence à la compilation.

[JolyLoic]

Il est clair qu'un certain nombre devrait devenir des erreurs de compilation. Genre les returns oubliés.
Sauf que la priorité est à la rétro-compatibilité sur les codes incorrects.

Ce n'est pas la seule raison. Par exemple, sur les return, pour éviter les comportements indéfinis, on a le choix entre imposer de mettre des return là où ils ne seront jamais utiles, et résoudre le problème de l'arrêt.