Code unreachable, pourquoi ?

Version imprimable

19/01/2009, 21h06
ram-0000

Code unreachable, pourquoi ?
Bonjour,

dans ce code:
Code:

1 2 3 4 5 6 7 8 9 10 int a; try { a = 12; } catch(...) { assert(false); // warning compilateur ici }
J'ai un warning du compilateur qui me dit :

Citation:

warning C4702: impossible d'atteindre le code

Le warning est sur la ligne de l'assert et je ne comprends pas pourquoi.
Bon, là, c'est un code minimal mais normallement dans le bloc try, il y a plein de choses.

Mon environnement de développement,
Visual Studio 2005 SP1 sur XP pro SP3, tout le monde est à jour des mises à jour.

Je compile une DLL,
la ligne de commande du compilateur est :

Code:

/Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_USRDLL" /D "WINLOG_EXPORTS" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W4 /nologo /c /Wp64 /ZI /TP /errorReport:prompt

La ligne de commande du linker est :

Code:

/OUT:"D:\Raymond\Developpement\WinLog\Debug\WinLog.dll" /INCREMENTAL /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Debug\WinLog.dll.intermediate.manifest" /DEBUG /PDB:"d:\Raymond\Developpement\WinLog\Debug\WinLog.pdb" /SUBSYSTEM:WINDOWS /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Si vous avez des idées, je suis preneur
19/01/2009, 21h10
Florian Goo

Je suppose que tu as le même warning avec un code moins trivial qu'une affectation à un int, sinon tu ne poserais pas la question, n'est-ce pas ?
19/01/2009, 21h13
Alp

Ca se comprendrait que ce ne soit pas le cas, car a = 12 quand a est de type int ne lèvera jamais d'exception.

Mais ça me semble bizarre que le compilo regarde si le code lèvera effectivement une exception ou non...
19/01/2009, 21h13
ram-0000

Citation:

Envoyé par Florian Goo

Je suppose que tu as le même warning avec un code moins trivial qu'une affectation à un int, sinon tu ne poserais pas la question, n'est-ce pas ?

Yes sir !!
Le code dans le bloc try est un tout petit peu plus complexe, j'ai simplifié :P
En fait, dans le bloc try, il y a des sprintf et des manipulation de chaines de caractères
19/01/2009, 21h15
Alp

Tu peux nous le donner, car il semble que ce soit le contenu du try qui pose problème, bien que je n'en sois pas sûr.
19/01/2009, 21h17
Alp

http://bytes.com/groups/c/484825-unreachable-code
pourrait éventuellement aider.

Hélas, je ne peux pas reproduire avec GCC :(

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <cassert>
 
int main()
{
	int a;
	try
	{
		a = 12;
	}
	catch(...)
	{
		assert(false); // warning compilateur ici
	}
}

Code:

1
2
 
g++ main.cpp -W -Wall -pedantic

19/01/2009, 21h22
ram-0000
Ce code reproduit le warning
Code:

1 2 3 4 5 6 7 8 9 10 int a = 12; int b = 0; try { a = a / b; } catch(...) { assert(false); }
Avec le débugger, j'ai effectivement une exception qui est levée mais je ne passe pas dans le bloc catch

Est ce qu'il est possible que la déclaration/définition de la fonction y soit pour quelque chose :
Code:

1 2 3 4 5 6 7 8 #ifdef __cplusplus extern "C" { #endif __cdecl int WinLogW(const int Event, const int FeatureLevel, const wchar_t * Format, ...); #ifdef __cplusplus } #endif
Le fait que cela soit une fonction "C" avec __cdecl :question:

Petit rappel, je compile une DLL
19/01/2009, 21h26
ram-0000

Citation:

Envoyé par Alp

http://bytes.com/groups/c/484825-unreachable-code
pourrait éventuellement aider.

Bonne réponse Alp, c'est cela

Citation:

I would assume that "C" functions must not throw, so any function is not expected to throw and code is not prepared to catch the exception raised by a "C"-function (->unreachable code)
19/01/2009, 22h32
koala01
Salut,

N'oublie pas qu'une division par 0 ne lance pas une exception...

Cela lance un signal d'erreur (SIGFPE -- FPE_INTDIV_TRAP ou FPE_FLTDIV_TRAP)

Outre le fait que try... catch ne fonctionne pas en C, tu dois donc tester la valeur du diviseur avant de laisser ce signal survenir (ou trouver le moyen de l'attraper, mais je crains que ca ne provoque un exit() impossible à attraper)...

En C, tu pourrait déjà faire un simple assert(b!=0), voire passer par un code sensiblement proche de
Code:

1 2 3 4 5 6 7 8 if(b==0) { /*que faire si le diviseur vaut 0 */ } else { traitement "normal" }
En C++, tu pourrais en arriver à un
Code:

1 2 3 4 5 6 7 8 9 try { if(b==0) throw DivideByZero(); } catch(DivideByZero const& ex) { /* ce qu'il faut faire */ }
20/01/2009, 08h39
ram-0000

Citation:

Envoyé par koala01

N'oublie pas qu'une division par 0 ne lance pas une exception...

Cela lance un signal d'erreur (SIGFPE -- FPE_INTDIV_TRAP ou FPE_FLTDIV_TRAP)

La nuance est peut être subtile mais le résultat est le même, cela passe (ou devrait passer) dans le catch sauf dans le cas de ma fonction "C" puisque les exceptions ne sont pas gérées par le code assembleur généré (structure de la pile ?)

Citation:

Envoyé par koala01

Outre le fait que try... catch ne fonctionne pas en C

C'est du code C++ compilé par un compilateur C++ avec comme particularité que la fonction doit pouvoir être appelée en C et donc elle possède un interface C.

Citation:

Envoyé par koala01

tu dois donc tester la valeur du diviseur avant de laisser ce signal survenir (ou trouver le moyen de l'attraper, mais je crains que ca ne provoque un exit() impossible à attraper)...

La division par 0 est un exemple minimal qui reproduisait mon problème de "code unreachable" mais qui n'est pas représentatif du vrai code
20/01/2009, 10h39
loufoque

Non. Une division par 0 lève un comportement indéfini. Ça ne lève pas une exception.

Avec MSVC++, ça soulève une exception structurelle, qui est très diifférente des exceptions C++, mais c'est spécifique à cette plate-forme.
20/01/2009, 11h06
Médinoc

Le problème majeur, c'est que sous Visual 6, catch(...) attrapait aussi les exceptions structurelles. Cela a été aboli pour une meilleure conformité au standard.
20/01/2009, 11h27
white_tentacle

Citation:

La nuance est peut être subtile mais le résultat est le même, cela passe (ou devrait passer) dans le catch sauf dans le cas de ma fonction "C" puisque les exceptions ne sont pas gérées par le code assembleur généré (structure de la pile ?)

compile avec /EHs à priori.

http://msdn.microsoft.com/en-us/libr...x5(VS.80).aspx
20/01/2009, 11h35
ram-0000

Citation:

Envoyé par white_tentacle

compile avec /EHs à priori.

Oui aussi.
Sinon, j'allai faire une fonction interne qui ne soit pas extern "C" avec les try/catch dedans
20/01/2009, 11h42
Médinoc

Une fonction peut être extern "C" et avoir les try/catch.
Par contre, une fonction extern "C" est supposée nothrow.
20/01/2009, 12h34
koala01

Au temps pour moi, j'avais l'idée (mais ou ai-je été la pêcher :question:) qu'une fonction extern C était compilée avec le compilateur... C...

Ce n'est donc que le name mangling qui assure la compatibilité, et non le code qu'elle contient :question:

Est-ce confirmé :question:

Si oui, je me coucherai moins bête que je ne l'étais ce matin en me levant :D
20/01/2009, 12h40
Médinoc

Je pense que c'est confirmé, vu qu'une fonction C++ extern "C" contient du code C++...
17/02/2009, 17h57
NiamorH

Si Visual lance une exception structurelle, et qu'il ne catch plus les exceptions structurelles depuis VC6, pourquoi dans la MSDN de 2008 je trouve ceci :

Citation:

Envoyé par MSDN 2008

If the exception-declaration statement is an ellipsis (...), the catch clause handles any type of exception, including C exceptions and system- or application-generated exceptions such as memory protection, divide by zero, and floating-point violations.
17/02/2009, 18h02
Médinoc

Parce qu'en fait, ça dépend d'un réglage du compilo.

Avec le paramètre /EHsc ou /EHs il ne les catche pas, mais avec /EHa, si.

Edit: Sachant que Visual 2005 utilise /EHsc par défaut, sans doute pour de meilleures performances. Pour 2008, je ne sais pas.