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 !