J'ai ce code: qui fonctionne parfaitement bien, mais je me demandais ce qui se passerait si je passe la valeur variable au lieu de la référence variable dans Je ne reçois pas d'erreur du compilateur mais il n'y a pas de sortie non plus.
Qu'est-ce qui se passe ici? P> P> scanf code> Comme
scanf ("% d", a) code>. p>
3 Réponses :
dans scanf faire cela invoquera comportement non défini . P> "% d" code> attend un pointeur sur
int code> signifie un pointeur sur l'adresse de la variable où la valeur sera stockée, si vous passez
A code> Vous allez simplement passer
int code> Il n'y a aucun moyen que la valeur puisse être stockée car
scanf code> ne saura pas où. p>
Fondamentalement, le & est un opérateur qui renvoie l'adresse de l'opérande. Si vous donnez dans Scanf la variable A sans le &, il sera transmis à la valeur de la valeur, ce qui signifie que Scanf ne sera pas en mesure de définir sa valeur pour que vous puissiez voir. En passant par-référence par référence - en utilisant et passe en fait un pointeur sur A - permet à Scanf de la définir. P>
Le terme par référence i> n'existe pas dans le langage C. Les références sont une chose C ++. En C il n'y a que des pointeurs.
Le comportement en faisant cela est indéfini em> - le compilateur n'est pas tenu de délivrer un diagnostic lors de la traduction et que l'environnement d'exécution n'est pas nécessaire de lancer une certaine exception. Selon la valeur contenue dans sup> p> scanf code> attend l'argument correspondant au spécificateur de conversion
% d code> pour être l'adresse em> d'un objet
int code> objet (avec type
int * code>). Quoi que ce soit em> em>
A code> contient une adresse 1 sup>. p>
A code>, vous pouvez obtenir une erreur d'exécution ou vous pouvez encombrer un autre objet de données, ou votre code peut fonctionner sans aucune erreur apparente, ni quelque chose de complètement différent peut arriver. p>
p>
tailleof (int) == taille de (int *) code> - pour un système tel que x86_64, ce n'est pas le cas, donc
scanaf code> traitera des octets extérieur em> de
A code> dans le cadre d'une adresse.
ol>
Longue histoire courte: UB
Si vous n'obtenez pas de message d'erreur ou d'avertissement de votre compilateur, votre compilateur est défectueux. Assurez-vous que les avertissements sont allumés dans votre compilateur.
Vous espéreriez un crash dur (Segfault). Mais puisque la variable n'est pas initialisée, il y a une cote décente qu'il contient une valeur de pointeur laissée par un appel de fonction précédent. Maintenant, il ne s'écrasera pas mais de la mémoire corrompue silencieusement, très difficile à diagnostiquer.