Discussion :

[BoudBoulMan]

le comportement N'EST PAS défini.

En quoi le comportement de cout n'est pas défini? Il va faire autre chose qu'afficher la valeur de a?

[Thierry Chappuis]

En quoi le comportement de cout n'est pas défini? Il va faire autre chose qu'afficher la valeur de a?

Possible, selon http://www.developpez.net/forums/sho...7&postcount=19

Thierry

[screetch]

comme cité par corrector

Code :

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

1
2
3
4
5
6
7
8
#include <iostream>
 
int main()
{
	int a;
	std::cout << a;
	return 0;
}

sur visual studio 2005 en debug va t'afficher une boite de dialogue. Sous GCC, cela va afficher un truc (personne ne peut vraiment predire quoi).

Le comportement est donc indefini. CQFD.

Vous pensez que c'est defini car vous pensez que le compilateur va allouer de la place sur la pile, puis que vous allez afficher cette place sur la pile.

Pensez que je pourrais faire un compilateur qui n'alloue pas sur la pile, mais alloue a la demande de la memoire dynamique pour chaque variable. Comme c'est fait sur demande, tant que je ne fais rien je n'alloue pas. Du coup, lorsque je lis cette valeur je n'ai pas encore alloué de l'espace et ca va planter.

lire une valeur non initialisée est indefini, en general ca renvoie une valeur aleatoire (enfin, disons plutot determinée par laposition de saturne et l'age du capitaine, c'est a dire que avec deux executions la valeur sera sans doute identique) mais ce n'est pas la seule implementation possible, et visual studio ajoute une boite de dialogue qui pete a la figure a l'execution.

[Jean-Marc.Bourguet]

Euh, là, je me permets de douter: Où est le problème tant qu'on ne déréférence pas le pointeur ?

Il y a des cas où simplement accéder à un pointeur invalide (sans tenter de lire la zone pointée) peut poser un problème. Par exemple, charger un descripteur de segment invalide génère une exception sur un x86.

(Ce n'est pas bien formulé d'ailleurs : il faut lire "or if T is a non-class type, and T is not char or unsigned char, and if the object is uninitialized, ...". Parce que là...)

char peut avoir des trap value... unsigned char non.

En quoi le comportement de cout n'est pas défini? Il va faire autre chose qu'afficher la valeur de a?

Le problème est que la valeur de a n'est pas définie. Et ce qui se trouve par hasard en mémoire peut ne pas être une valeur acceptable. Par exemple il y a eu des machines à tag où chaque mot mémoire avait un tag décrivant son type. Sans initialisation, celui-ci peut être incorrect. Autre exemple, il y a eu une machine qui n'avait comme représentation numérique qu'une représentation flottante mais qui avait des instructions qui trappaient si une valeur n'était pas entière.

[corrector]

char peut avoir des trap value... unsigned char non.

Je ne pense pas que ça puisse être compatible avec ceci :

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined
[...]
— a char or unsigned char type.

ce qui suggère une contradiction avec la clause de non-initialisation.

Cette clause est vraiment troublante, car elle suggère de faire des choses que rien n'autorise; en effet, comment obtenir les lvalues suivantes :

— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a char or unsigned char type.

alors que

A pointer to an object can be explicitly converted to a pointer to an object of different type. [...] the result of such a pointer conversion is unspecified.

Dans ce cas, quel intérêt de nous raconter ça :

For each of the standard signed integer types, there exists a corresponding (but different) standard unsigned integer
type: “unsigned char”, “unsigned short int”, “unsigned int”, “unsigned long int”, and “unsigned long long int”, each of which occupies the same amount of storage and has the same alignment requirements (3.9) as the corresponding signed integer type; that is, each signed integer type has the same object representation as its corresponding unsigned integer type. [...] the value representation of each corresponding signed/unsigned type shall be the same.

Encore une phrase qui ne veut rien dire : comment un type signé pourrait avoir la même représentation qu'un type non-signé? En fait, il faut lire quelque chose comme :

The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of values in such range shall be the same in both types.

(Zut, moi qui voulais faire une réponse courte.)

Autre exemple, il y a eu une machine qui n'avait comme représentation numérique qu'une représentation flottante mais qui avait des instructions qui trappaient si une valeur n'était pas entière.

Tient, c'est rigolo comme architecture.

[corrector]

En quoi le comportement de cout n'est pas défini?

Où est-il défini?

Il va faire autre chose qu'afficher la valeur de a?

Potentiellement, reformater ton disque dur ou démarrer une partie de nethack.

En pratique, c'est vrai qu'il y a moins de risques qu'avec le déréférencement d'un pointeur non initialisé. Mais une variable non initialisée n'est pas juste une variable qui a une valeur inconnue.

[Jean-Marc.Bourguet]

Je ne pense pas que ça puisse être compatible avec ceci :

Ce n'est pas une enumeration de tous les cas de comportements indefini, mais de comportement qui sont a coup sur indefini. Subtile difference.

Je ne sais pas si ca a change depuis et je n'ai pas le temps de faire une recherche, mais la norme de 98 dit en 3.9.1/1 que char peut etre la meme chose que signed char, et que seul unsigned char est garanti avoir tous les bit patterns comme valeurs acceptables (cas du complement a 1...) meme si on est sur de ne pas avoir de bits ne participant pas a la valeur pour tous les types caracteres.

Si char etait enleve de ta citation, le comportement aurait ete rendu indefini meme dans les implementations pour lesquelles char equivaut a unsigned char. Tel que redige, le comportement est indefini uniquement pour celles ou char equivaut a signed char.

C'est la grosse difficulte de la lecture de la norme, il faut non seulement trouver une description, il faut aussi etre raisonablement sur que ce n'est pas modifie a d'autres endroits.

Pour le reste, j'ai des choses a repondre mais ca attendra que je puisse retrouver les citations adequates.

[corrector]

Ce n'est pas une enumeration de tous les cas de comportements indefini, mais de comportement qui sont a coup sur indefini. Subtile difference.

Formellement, oui. Mais pourquoi spécifier que le comportement est indéfini alors qu'il l'est déjà? (Pourquoi cette clause?)

Je ne sais pas si ca a change depuis et je n'ai pas le temps de faire une recherche, mais la norme de 98 dit en 3.9.1/1 que char peut etre la meme chose que signed char, et que seul unsigned char est garanti avoir tous les bit patterns comme valeurs acceptables (cas du complement a 1...) meme si on est sur de ne pas avoir de bits ne participant pas a la valeur pour tous les types caracteres.

Pas de changement :

For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types.

Je n'avais pas vu ça.

Si char etait enleve de ta citation, le comportement aurait ete rendu indefini meme dans les implementations pour lesquelles char equivaut a unsigned char. Tel que redige, le comportement est indefini uniquement pour celles ou char equivaut a signed char.

Oula!

Plus précisément : le comportement est indéfini pour les implémentations où CHAR_MAX - CHAR_MIN != UCHAR_MAX. Mais la norme C++ ne parle pas de "trap representation". Formellement, elle ne dit pas explicitement que c'est indéfini.

C'est la grosse difficulte de la lecture de la norme, il faut non seulement trouver une description, il faut aussi etre raisonablement sur que ce n'est pas modifie a d'autres endroits.

C'est pas de la tarte!

[Klaim]

O___O;

Merci pour les détails!
Une erreur d'attention de ma part (je n'ai pas vu l'ascence d'initialization de i dans l'exemple) aura mis en avant une obscure subtilitée du language