C++ est-il devenu un langage de script ?

je vais pr�ciser mon point de vue :

imaginez un sous ensemble du C++ (avec j'imagine un typage statique ultra fort)
qui garantisse que dans le pire des cas le programme ne s'arr�te pas, ou renvoie une exception pour avoir tent� d'acc�der � un pointeur null, qu'on s�che avant ex�cution exactement quel socket, quel fichier il va cr�er, de quelle taille, pour faire transiter quel genre de donn�es, et qu'il suffisse d'envoyer ce code source "safe" � microsoft/google/mozilla pour qu'ils le signent (automatiquement et en 5 minutes chrono), �a faciliterait la vie des anti-virus et des d�veloppeurs qui souhaitent distribuer leur application, non ?

M�me si ce n'est pas exactement organis� comme cela, java .net python javascript le permettent, C++ ne le permet pas encore.

Citation:

---

Envoy� par acx01b

M�me si ce n'est pas exactement organis� comme cela, java .net python javascript le permettent, C++ ne le permet pas encore.

---

Source ?

Je suis vraiment curieux de savoir ce qu�ils affirment �tre capables de faire dans ces langages. Il y a tellement de moyen de faire n�importe quoi que vraiment, �a me surprend beaucoup.

Je sais qu�on est capable de faire de le preuve de programme sur certains langages (et en particulier, pas en C++). Mais de l� � en d�duire des � comportements viraux �, alors qu�il est quasi impossible de d�finir ce qu�est un comportement de virus (par exemple : envoyer un fichier peut �tre un comportement normal comme un comportement de logiciel malveillant), je suis extr�mement dubitatif.

Et le nombre de merdes au comportement douteux sur les apps stores tend quand m�me � dire qu�effectivement, ce que tu d�cris rel�ve plus du monde id�al que de la r�alit�.

Citation:

---

Envoy� par acx01b

qui garantisse que dans le pire des cas le programme ne s'arr�te pas, ou renvoie une exception pour avoir tent� d'acc�der � un pointeur null, qu'on s�che avant ex�cution exactement quel socket, quel fichier il va cr�er, de quelle taille, pour faire transiter quel genre de donn�es, et qu'il suffisse d'envoyer ce code source "safe" � microsoft/google/mozilla pour qu'ils le signent (automatiquement et en 5 minutes chrono), �a faciliterait la vie des anti-virus et des d�veloppeurs qui souhaitent distribuer leur application, non ?

---

C'est n'importe quoi : ces informations sont la plupart du temps calcul�es � l'ex�cution, il est impossible pour un compilateur ou un analyseur statique de d�tecter ces probl�mes. Et ce quel que soit le langage : c'est du bon sens !

Pour ce type de probl�mes qui peuvent �tre trouv�s � la compilation, il existe le static analyzer de LLVM pour C++.

Citation:

---

Envoy� par acx01b

M�me si ce n'est pas exactement organis� comme cela, java .net python javascript le permettent, C++ ne le permet pas encore.

---

Tu dois s�rieusement revoir ta culture. Le seul truc que ces langages font en plus face � une situation impr�vue au runtime, c'est planter en affichant une stack gr�ce � l'exception. Tu peux aussi faire ce genre de choses en C++ si �a t'amuses, avec un bon gros try/catch dans ton main :aie:.

Citation:

---

Envoy� par Hinault Romaric

Pour se situer dans le contexte, Pakkanen estime qu�un langage de script diff�re d�un langage compil� comme C par les crit�res suivants :

*pas de gestion manuelle de la m�moire ;
*la syntaxe et les fonctionnalit�s complexes expressives peuvent �tre mises en �uvre en seulement quelques lignes de code ;
*des puissantes fonctions de manipulation de chaines ;
*une grande biblioth�que standard.

---

ce dont parle Pakkanen c'est en fait une s�rie de lapalissades ou tautologies ;
ce sont des affirmations dont le sens est �vident
Et �a n'apporte rien du tout comme mes pr�d�cesseurs l'ont montr�

Citation:

---

Envoy� par acx01b

je vais pr�ciser mon point de vue :

imaginez un sous ensemble du C++ (avec j'imagine un typage statique ultra fort)
qui garantisse que dans le pire des cas le programme ne s'arr�te pas, ou renvoie une exception pour avoir tent� d'acc�der � un pointeur null, qu'on s�che avant ex�cution exactement quel socket, quel fichier il va cr�er, de quelle taille, pour faire transiter quel genre de donn�es, et qu'il suffisse d'envoyer ce code source "safe" � microsoft/google/mozilla pour qu'ils le signent (automatiquement et en 5 minutes chrono), �a faciliterait la vie des anti-virus et des d�veloppeurs qui souhaitent distribuer leur application, non ?

M�me si ce n'est pas exactement organis� comme cela, java .net python javascript le permettent, C++ ne le permet pas encore.

---

Les compilateurs ne garantissent absolument rien. Tout au plus peut-on �crire un manifeste pour une application qui indique � la machine virtuelle que l'application n'a pas besoin d'avoir acc�s au syst�me de fichier ou au r�seau par exemple et dans ce cas, la machine virtuelle lui en interdit l'acc�s.

Il n'y a aucun moyen de savoir que du code est malveillant ou non sans en faire une analyse dynamique ce qui revient � l'ex�cuter d'une mani�re ou d'une autre, et l� encore il n'est pas question de garantir quoi que ce soit, il n'y a qu'� voir le nombre de faux positif et plus grave de faux n�gatif des anti-virus!

Bonjour.

Citation:

---

Envoy� par acx01b

...le programme ... qu'on s�che avant ex�cution exactement .... quel fichier il va cr�er...

M�me si ce n'est pas exactement organis� comme cela, java .net python javascript le permettent, C++ ne le permet pas encore.

---

Donc avec java .net python javascript, on peut savoir quel fichier va �tre cr��, mais pas en C++.

Des d�tails sur ce point s'impose. Je suis un peu largu�.

Code:

---

1 2 3

Donc avec java .net python javascript, on peut savoir quel fichier va être créé, mais pas en C++.   Des détails sur ce point s'impose. Je suis un peu largué.

---

Du r�ve en couleur...je bosses r�guli�rement en Java, c'est productif, �a pardonne (un peu) l'inexp�rience, mais y'a pas de baguette magique anti-intrusion.
Disons qu'il y a opportunit� pour mutualiser un peu plus de travail de s�curit� au niveau de la JVM, mais �a fait pas le caf� non plus, faut pas r�ver...

Citation:

---

Envoy� par acx01b

imaginez un sous ensemble du C++ (avec j'imagine un typage statique ultra fort)
qui garantisse que dans le pire des cas le programme ne s'arr�te pas

---

Donc tu veux un sous-ensemble qui ne soit pas complet au sens de Turing?

Citation:

---

ou renvoie une exception pour avoir tent� d'acc�der � un pointeur null

---

C'est un UB, tu peux deja faire un compilo qui fasse ce que tu veux.

Citation:

---

qu'on s�che avant ex�cution exactement quel socket, quel fichier il va cr�er, de quelle taille, pour faire transiter quel genre de donn�es,

---

A nouveau impossible theoriquement sauf a limiter le langage.

Citation:

---

M�me si ce n'est pas exactement organis� comme cela, java .net python javascript le permettent, C++ ne le permet pas encore.

---

Java, C# (.NET n'est pas un langage), Python sont complet au sens de Turing, donc ne remplissent pas tes desirs.

Celui de tes desirs qui est realisable ne demande qu'un compilateur pret a l'implementer. (Ca ne m'etonnerait pas que ca ait deja ete fait pour gcc, ca ne m'etonnerait pas que ce soit realisable dans un plugin de gcc).

Le coup du Java/.Net contre C++, c'est que les premiers peuvent contr�ler quels composants d'un m�me processus ont acc�s � quelles ressources (fichiers etc.).

Et cela se base sur une condition simple que C++ ne remplit pas: Le langage ne doit pas offrir au code non "trusted" de m�canisme permettant de trafiquer la pile d'appels. C'est ce qui permet � des plate-formes comme .Net de d�terminer quel code a appel� une fonction comme File.Open().
Tant que l'interpr�teur (ou compilateur JIT), lorsqu'il ex�cute un code suspect, rejette toute instruction d'arithm�tique de pointeurs, la pile est sauve et le code ne peut pas s'en servir pour se faire passer pour un autre composant.

Citation:

---

Envoy� par M�dinoc

Le coup du Java/.Net contre C++, c'est que les premiers peuvent contr�ler quels composants d'un m�me processus ont acc�s � quelles ressources (fichiers etc.).

Et cela se base sur une condition simple que C++ ne remplit pas: Le langage ne doit pas offrir au code non "trusted" de m�canisme permettant de trafiquer la pile d'appels. C'est ce qui permet � des plate-formes comme .Net de d�terminer quel code a appel� une fonction comme File.Open().
Tant que l'interpr�teur (ou compilateur JIT), lorsqu'il ex�cute un code suspect, rejette toute instruction d'arithm�tique de pointeurs, la pile est sauve et le code ne peut pas s'en servir pour se faire passer pour un autre composant.

---

Comme tu le dis si bien, c'est le job de l'ex�cuteur (que ce soit un interpr�teur, une machine virtuelle ou un syst�me d'exploitation), pas du langage. Rien, mais alors, strictement rien, n'interdit de faire une machine virtuelle C++ qui fasse �a.

Pour �tre pr�cis, c'est m�me ce que certains jeux �crits en C font. Un indice? QVM.
Si c'est faisable en C, c'est faisable en C++.... ah, bah, d'ailleurs, m�me que c'est faisable avec LLVM. A ce sujet, aux derni�res nouvelles que j'ai eu, les d�veloppeurs d' unvanquished veulent justement migrer de QVM a LLVM, pour pouvoir utiliser C++. Je te filerai pas de lien pour cette technique, j'ai la flemme de faire des recherches.

Ah, et pour finir d'enfoncer le clou, l'inconv�nient majeur de ton truc, c'est pour les ex�cutables auto-compress�s. Notes bien que cette utilisation n'est pas critique, � premi�re vue... sauf que, c'est aussi utilis� pour prot�ger le code contre les m�chants crackers. M�chants crackeurs qui sont g�n�ralement assez heureux d'avoir � s'occuper de programmes en Java ou utilisant le bytecode MS, parce que c'est quand m�me vachement plus simple � lire que de l'asm x86, m�me sans les commentaires, noms de fonction internes et noms de variables.

QVM fait aussi participer le compilateur, et ne passe pas directement de l'asm x86 � sa VM:

Citation:

---

LCC is used with a special parameter so it does not output a PE (Windows Portable Executable) but rather its Intermediate Representation which is text based stack machine assembly.

---

En fait, tu as raison sur le fait que le probl�me n'est pas tant au niveau du front-end (le langage peut �tre C, C++, brainfuck, VB, C#, etc.) qu'au niveau d'avoir, en entr�e de la VM, le code dans une repr�sentation qui permet de garantir facilement qu'aucune arithm�tique de pointeur (y compris conversions entre entiers et pointeurs) n'a lieu. Ce qui est beaucoup plus facile en CIL et Java qu'en assembleur x86 (bien que ce soit probablement faisable m�me en assembleur pour la plupart des programmes. Pas pour tous par contre, parce que je pense que �a reviendrait � r�soudre le probl�me d'arr�t).

Au passage, .Net n'emp�che pas un ex�cutable d'�tre auto-compress�, vu qu'un assembly peut �tre charg� depuis un tableau de bytes.

En passant, https://code.google.com/p/nativeclient/

je ne voulais pas avancer l'argument de "en C++ on peut trafiquer la pile d'appel" m�me si c'est celui auquel je pensais au d�part, merci m�dinoc d'avoir �voqu� le probl�me pour l'OS de d�terminer "qui" a appel� f.open(), en C++ on peut le tromper assez facilement,

Je suis convaincu que Ne pas pouvoir bidouiller la pile d'appel, ne pas pouvoir ex�cuter le code machine que l'on veut c'est la base pour limiter la propagation des virus d'un process � l'autre / d'un ordi � l'autre.

En plus de �a je reste sur l'id�e que �a serait bien au compilateur/parseur/analyseur statique de transformer un code haut niveau qui est prouv� comme "ne faisant rien de tr�s dangereux" en bytecode et enfin de signer celui-ci.

Il suffit d'imaginer comme je l'�voquais que ce compilateur soit situ� physiquement chez microsoft/google/mozilla pour donner confiance � celui qui ex�cutera le programme.

Rien n'emp�che de d�terminer un sous ensemble du C++ qui permette de v�rifier statiquement quelles api sont appel�es, avec quels "types" d'arguments (et non pas quelles valeurs), par exemple :

Code:

---

1 2	f = open(temporaryFolder() + "monFichier.txt"); f << myObject.serialize();

---

Je reste aussi sur l'id�e que C#/.NET a plus ou moins r�ussi � d�terminer un sous ensemble de cet ordre (sachant que de mon point de vue, l'id�e de C#/.NET c'est qu'il peut se traduire mot � mot en C++ en rempla�ant . par -> ) sauf qu'ils ont �galement impos� le dynamic_cast comme seul op�rateur de cast, le garbage collector pour tous les objets allou�s avec new, et en cons�quence la r�flexion pour tous les objets allou�s avec new.

En C#/.NET (en exluant les codes dits unsafe), dans le pire cas, un pointeur est nul, il ne peut jamais pointer vers un objet invalide.

J'ai l'intuition que le dynamic_cast et en cons�quence la r�flexion (dynamique, c'est � dire myObject->GetType() ) est indispensable pour qu'un langage (avec objets polymorphes) soit "safe", par contre le garbage collector j'ai l'intuition que ce n'est pas forc�ment indispensable.

Pas de probl�me ;)
Je dois tout �a � Raymond Chen.

Citation:

---

Envoy� par acx01b

J'ai l'intuition que le dynamic_cast et en cons�quence la r�flexion (dynamique, c'est � dire myObject->GetType() ) est indispensable pour qu'un langage (avec objets polymorphes) soit "safe", par contre le garbage collector j'ai l'intuition que ce n'est pas forc�ment indispensable.

---

Pourquoi? Une VM dans le genre VMware ne l'est pas? Faut vite le dire � IBM, �a ne fait que 40 ans qu'il le vende.

non �a m'int�resse, c'est quoi leur strat�gie � VMware pour rendre plus safe les codes C++ ?

apr�s pas besoin de me convaincre qu'ex�cuter chaque programme sur un pc diff�rent non connect� au r�seau �a limite beaucoup les risques li�s aux codes malveillants, et donc la strat�gie de simuler des pc diff�rents sur un m�me pc c'est tr�s safe (et probablement la meilleure solution sur un serveur web partag� par plusieurs sites), c'est ce que fait VMware ?

C'est l'id�e (simuler n'est pas le bon mot, ils utilisent du support dans le processeur, donc la vitesse d'ex�cution est presque celle que tu peux avoir sans cette couche).

Tes posts sont priceless acx01b.

Citation:

---

Envoy� par acx01b

En plus de �a je reste sur l'id�e que �a serait bien au compilateur/parseur/analyseur statique de transformer un code haut niveau qui est prouv� comme "ne faisant rien de tr�s dangereux" en bytecode et enfin de signer celui-ci.

---

Ca tombe bien c'est d�j� ce que font les compilateurs : transformer le code de haut niveau en code de bas niveau.

Mais je supose que tu voulais dire, bien que ce ne soit pas le sens de ta phrase, que le compilateur est aussi responsable de "prouver que le code ne fait rien de trop dangereux" ?

Tu seras heureux d'apprendre que c'est une gross�re erreur de logique, ceci n'est pas faisable en C++ ni dans aucun autre langage. La d�finition de "ne rien faire de trop dangereux" d�pend de l'utilisateur, de sa machine, du contexte dans lequel il sougaite ex�cuter le programme, etc. Cette �tape ne peut �tre r�alis�e qu'� l'ex�cution. Pire, il n'est pas souhaitable qu'elle le soit � la compilation. Je ne veux pas d'un logiciel qui d�cide � ma place des ressources auxquelles il a le droit d'acc�der. C'est moi qui d�cide. Pas le programme. Et pas le compilateur.

Pour ne rien arranger, tu devrrais savoir que le comportement d'un programme n'est pas pr�dictible statiquement (� part des cas particuliers inutiles), mais si tu penses pouvoir prouver le contraire, �a va int�resser un paquet de chercheurs. Go ahead.

Citation:

---

Envoy� par acx01b

Il suffit d'imaginer comme je l'�voquais que ce compilateur soit situ� physiquement chez microsoft/google/mozilla pour donner confiance � celui qui ex�cutera le programme.

---

La confiance dans un logiciel tiers n'est pas un probl�me r�cent et ne se limite pas � "confier la validation et la signature � une grosse bo�te", c'est nettement plus complexe que �a !

Citation:

---

Envoy� par acx01b

Rien n'emp�che de d�terminer un sous ensemble du C++ qui permette de v�rifier statiquement quelles api sont appel�es, avec quels "types" d'arguments (et non pas quelles valeurs)

---

Si je comprend bien, tu reproches � C++ de n'�tre pas assez fortement typ� :aie: ?

Au passage, le RTTI, ce n'est pas de la r�flexion.

L'intuition, c'est parfois bien, la compr�hension bas�e sur des faits et des connaissances, c'est mieux.

Citation:

---

Envoy� par jblecanard

Mais je supose que tu voulais dire, bien que ce ne soit pas le sens de ta phrase, que le compilateur est aussi responsable de "prouver que le code ne fait rien de trop dangereux" ?

Tu seras heureux d'apprendre que c'est une gross�re erreur de logique, ceci n'est pas faisable en C++ ni dans aucun autre langage. La d�finition de "ne rien faire de trop dangereux" d�pend de l'utilisateur, de sa machine, du contexte dans lequel il sougaite ex�cuter le programme, etc. Cette �tape ne peut �tre r�alis�e qu'� l'ex�cution. Pire, il n'est pas souhaitable qu'elle le soit � la compilation. Je ne veux pas d'un logiciel qui d�cide � ma place des ressources auxquelles il a le droit d'acc�der. C'est moi qui d�cide. Pas le programme. Et pas le compilateur.

---

Je pense que "ne fait rien de trop dangereux ici" signifie "est incapable de se faire passer pour un autre" (spoof de la pile d'appels, etc.). Toutes les restrictions de s�gr�gation au sein d'un m�me processus (qui sont, elles, g�r�es � l'ex�cution comme du le dis) d�pendent de �a.
Il appartient donc au compilateur de produire du code que .Net appelle "v�rifiable" (mais c'est � l'environnement d'ex�cution que revient le fait de v�rifier, comme tu l'as dit).

Citation:

---

Je ne veux pas d'un logiciel qui d�cide � ma place des ressources auxquelles il a le droit d'acc�der. C'est moi qui d�cide. Pas le programme. Et pas le compilateur.

---

100% d'accord. Je d�teste quand les apps Android font �a.

Citation:

---

Envoy� par jblecanard

Tes posts sont priceless acx01b.

L'intuition, c'est parfois bien, la compr�hension bas�e sur des faits et des connaissances, c'est mieux.

---

Non mais c'est hallucinant l'�tat d'esprit qui r�gne ici.

Que tu aurais pr�f�r� que je sois plus pr�cis avec les concepts de r�flexions et de RTTI n'est pas stupide, mais la mani�re dont tu le fais savoir l'est � 300%. Merci d'avance de ne plus jamais r�pondre � quelqu'un sur ce ton l� afin de prouver au monde qu'on peut �tre passionn� d'informatique sans �tre compl�tement autiste pour autant !