Une division par 0 qui donne 0 !

Version imprimable

27/02/2019, 18h54
Captain'Flam

Une division par 0 qui donne 0 !
Bonjour,
je compile+exécute ce
Code:

1 2 3 4 5 int main () { int x = (1/0) - 1 ; return x ; }
sous Visual Studio 2017 en Win64, et la valeur affectée à x est -1 !
je n'ai pas essayé en 32 bits, ni avec d'autres version de Visual, mais tout de même, ça laisse songeur... 8O
Pour info, avec x = (1/0) ; j'ai bien une erreur div by 0 à la compilation.

Suis-je le seul dans ce cas ?
Merci de vos avis/remarques...
27/02/2019, 21h17
Christophe
Capitaine Flam, tu es d'une autre galaxie ....

Compilé en l'état sous gcc :
Code:

1 2 test.c: In function ‘main’: test.c:3:15: warning: division by zero [-Wdiv-by-zero]
et à l’exécution :
Code:

1 2 3 ./a.out Exception en point flottant
27/02/2019, 21h25
Bousk

VS 2017 semble supprimer l'opération.

Code:

mov dword ptr [x],0FFFFFFFFh

C'est abusif je trouve, mais écrire ce code est de toutes façons faux et ne devrait jamais être fait donc bon.
27/02/2019, 21h32
Christophe

Il ne fait pas de warning VC 2017 ?
27/02/2019, 21h46
Bousk

Non aucun, même avec /Wall.
28/02/2019, 02h22
jo_link_noir

Le compilateur est libre de faire ce qu'il veut lorsque le code est invalide.

clang ne met pas de valeur de retour et gcc utilise une exception d'opcode invalide (en -O3) ou une exception sur les flottants est lancé par le matériel. https://godbolt.org/z/3kFe0m

Par contre, mettre simplement int x = 1/0; ne compile pas avec msvc: error C2124: divide or mod by zero.
28/02/2019, 11h54
Bktero

Si c'est un undefined behavior, tout peut arriver...
28/02/2019, 14h47
Sve@r

Citation:

Envoyé par Captain'Flam

sous Visual Studio 2017 en Win64, et la valeur affectée à x est -1 !

Suis-je le seul dans ce cas ?
Merci de vos avis/remarques...

Bonjour

Moi aussi, j'ai compilé avec gcc et j'ai comme chrtophe.

J'ai toutefois une petite question idiote (ne connaissant pas le monde Microsoft/VS). T'es sûr que la sortie est "-1" ? Si par exemple je fais une analogie avec le monde Unix/Linux, la sortie d'un programme donne une valeur comprise entre 0 et 255 (donc modulée si le programme retourne une valeur dépassant ces limites). Il est donc tout à fait possible qu'il y ait modfication entre ce que sort ton code et la façon dont Windows le récupère non ? Moi si j'avais fait cette expérimentation, je l'aurais plutôt affichée dans mon code via un printf("%d\n", x) plutôt que d'envoyer cette valeur à l'OS. Et de fait, c'est ce que j'ai fait en réalité.

Sinon en allant dans l'absolu, t'as tenté de remplacer ton "-1" par un "+1" ? Parce que bon, faire une opération illégale déjà c'est chaud pour déterminer ce qui se passe mais si en plus tu lui rajoutes des contraintes liées à la soustraction (extension du bit de signe, etc) ça complexifie encore plus ta recherche non ?

Citation:

Envoyé par chrtophe

Capitaine Flam, tu es d'une autre galaxie ....

C'est pas tout à fait exact. La chanson ne dit pas qu'il est d'une autre galaxie, mais dit en réalité qu'il n'est pas de la notre. Un peu comme si je concluais que Dumbo est un chat parce que quelqu'un me dit qu'il n'est pas un chien (Sophisme donc).
Et elle rajoute "mais du fond de la nuit". Donc il est en réalité du fond de la nuit...

Citation:

Envoyé par Bktero

Si c'est un undefined behavior, tout peut arriver...

Tu es notre Salomon :mouarf:
28/02/2019, 21h02
Christophe

Citation:

Le compilateur est libre de faire ce qu'il veut lorsque le code est invalide.

Ah bon ? Pour moi il ne devrait pas compiler ce code invalide. Pour moi écrire x=(1/0) -1 revient à soustraire 2 constantes dont une est non évaluable, donc invalide. Déjà juste un warning avec gcc c'est gentil je trouve.
28/02/2019, 23h46
JolyLoic

Il y a plusieurs niveaux de code invalide, avec des différences très subtiles entre elles... Plus de détail là : https://en.cppreference.com/w/cpp/language/ub

En gros, dans ce cas, il serait simple de diagnostiquer la division par 0. Mais dans le cas général, ce n'est pas possible. Et donc la norme ne va pas imposer à un compilateur de le faire. Après, ce que fait réellement un compilo ou un autre, c'est comme il en a envie (on parle généralement de QoI, quality of implementation).Et là, on peut dire qu'on aimerait probablement avoir mieux... Mais comme d'un autre côté, c'est artificiel comme exemple, veut-on vraiment que les devs du compilateur passent leur temps là dessus ?
01/03/2019, 12h02
Captain'Flam

Merci à tous pour vos commentaire avisés.
Pour information je ne viens pas de la galaxie ou on calcule des divisions par zéro pour le plaisir d'écrire du code loufoque :cfou:

Parmi mes outils perso de C/C++, j'ai une macro (COMPIL_ASSERT) qui dépend d'une condition.
Si la condition est vérifié, l'évaluation de la macro donne 0.
Sinon, elle tombe sur une division par zéro.

Si le compilateur lève une erreur en cas de division par zéro (ce que je croyais certain) cette macro permet de tester certaines conditions à la compilation.
Par exemple, dans un projet multi plateforme (qui doit fonctionner même avec des compilateurs antédiluviens),
il peut être très utile d'ajouter COMPIL_ASSERT( sizeof( void* ) == sizeof( long )) quelque part dans le code.

Mais depuis que j'ai installé Visual 2017, ces vérifications de vérifient plus rien...
Et j'ai simplifié cette macro au maximum pour vous soumettre un code aussi simple que possible.

Depuis, j'ai trouvé une autre astuce : ma macro déclare un tableau de dimension -1 si la condition n'est pas vérifiée.
Mais je n'ai pas encore testé tous les compilateurs avec lesquels je suis amené à travailler.
01/03/2019, 14h17
Bousk

Déclarer un tableau de taille -1 est l'implémentation que j'ai toujours vu pour ceci.
Maintenant C++11 a ajouté ça dans le standard static_assert.
01/03/2019, 15h06
Captain'Flam

Ahhh static_assert, comme c'est beau, sobre et élégant...
Malheureusement, non seulement mon projet n'est pas en C++, mais en plus il doit rester compatible C89 ! :roll:
Je l'ai posté sur le forum C++ parce que le framework de test (qui n'est pas livré aux clients) est en C++ (et que c'est en travaillant dessus que j'ai constaté ce pb).

Pour en rajouter une couche, j'ajouterais que l'absence d'un simple warning me parait hautement dangereuse...
Dans le cadre de post, ma macro ne sert qu'à faire un simili static_assert, mais on peut en imaginer une autre qui fasse un calcul réellement utilisé dans le code.
Dans ce cas, si une constante change quelque part et conduit ce calcul de macro à une division par zéro, on aimerait en être informé...
01/03/2019, 17h04
Bousk

Sur un forum C++ on te fournit des réponses C++.
Si maintenant ton projet n'est pas en C++, alors le problème initial change..

Mais static_assert n'a pas attendu C++11 pour exister.
Et bien entendu il existe des implémentations en C.
http://www.drdobbs.com/compile-time-...ions/184401873

Et ceci est l'implémentation que j'ai généralement vu un peu partout dans des codebases évolués du C #define assert_static(e) { char assert_static__[(e) ? 1 : -1] }

https://stackoverflow.com/a/3385694
Avec des variantes utilisant typedef et incluant un message #define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1] mais qui ne marchent pas dans des déclarations (donc intérêt limité imo).
Donc la solution typedef est moins bonne imo, mais l'ajout du message peut être combiné à l'autre solution.

Maintenant, mieux vaut utiliser celles fournies par le standard.
Il semble qu'elles existent aussi dans C11 et ne sont donc pas limitées au C++11.
Si un jour tu peux faire évoluer le truc, ou sur un autre projet.
01/03/2019, 18h08
Christophe

Citation:

Pour information je ne viens pas de la galaxie ou on calcule des divisions par zéro pour le plaisir d'écrire du code loufoque

Pour moi c'était une boutade lié à ton pseudo et que je trouvait le résultat de VC surréaliste. Je n'ai pas les compétences C pour savoir si VC respecte les normes en faisant ce qu'il te fait.

Mon test a été fait avec gcc 4.7.2. Je ne sais pas quelle norme il utilise (C89, C99, etc.)