Nicolas Boulay a écrit 15824 commentaires

L'effort n'est pas délirant par rapport à trouver le problème à la main. (genre le code plante parce qu'une fonction à coté fait un débordement de buffer sur une variable global...)

"La première sécurité est la liberté"

tu exagères un poil. Ils ont plein de serveur pour faire du partagé. De plus, ils monitorent aussi leur réseau pour couper les serveurs compromis.

"La première sécurité est la liberté"

Tu aurais été embêté pour faire de la compilation séparée sans les .h.

"La première sécurité est la liberté"

Oui et non.

C'est censé être standard, mais c'est hyper complexe. De plus, l'information existe et peut donc être utilisé.

"La première sécurité est la liberté"

Bah oui.

La technologie pour faire exécuter un code, n'est pas lié au langage lui-même mais aux choix fait pour l'exécuter. Cf par exemple l'utilisation de tcc pour transformer du C en script shell en utilisant une sorte de JIT.

C'est plus ou moins simple selon les cas. ocaml par exemple peut être compiler ou interprété.

"La première sécurité est la liberté"

Ok, donc toi ta définition de VM, c'est VM = JIT.

non, les premières VM n'étaient pas JIT. JIT implique une compilation en code natif à la volé, cela ne couvre pas les interprétations directs du bytecode.

"La première sécurité est la liberté"

En C++, tu as le mangling des méthodes qui permet de retrouver aussi les types des paramètres et les interfaces.

"La première sécurité est la liberté"

Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.

Si tu compiles en natif, il n'y a plus de VM. Un langage de haut niveau n'a pas forcément besoin d'une VM, c'est ça que tu ne veux pas comprendre.

dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.

Ben non. VM !=abstraction.

"La première sécurité est la liberté"

Si, le jeu d'instruction. Soit c'est un bytecode, soit c'est du x86/x86-64/ppc/arm/mips...

"La première sécurité est la liberté"

L'incompétence n'est pas une excuse.

tu peux trouver aussi des subtilités dans C#, je suis quasiement sûr que gérer proprement les exceptions ne doit pas être simple.

"La première sécurité est la liberté"

En gros, il sous-entende qu'il pourrait attaquer avec les autres brevets de l'api, la belle affaire.

"La première sécurité est la liberté"

donc en C à cause des fonction comme longjump, setjump, c'est aussi une VM ?

"La première sécurité est la liberté"

C'est une construction du langage comme if, while ou goto qui générer ensuite des instructions machines.

"La première sécurité est la liberté"

C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.

Abstraire la machine est le role des OS et des langages par rapport à m'asm pur et dur. Linux tourne bien sur plein d'archi différentes mais les logiciels C tournent tous dessus.

une VM ce n'est pas que ça. C'est aussi un jeu d'instruction particuliers.

"La première sécurité est la liberté"

Comme C# ca tombe bien.

Mais pas les API (.NET ASP ?) qui sont elle breveté et ne font pas partie de la "promesse" de MS.

Donc, non ce n'est pas pareil.

"La première sécurité est la liberté"

En C# tu peux aussi demander à ton code d'effacer ton disque dure, rien n'empêchera de faire ce genre de bêtise.

"La première sécurité est la liberté"

Ils tiennent parole pour attaquer Linux. Pourquoi donc leur faire confiance ensuite ?

"La première sécurité est la liberté"

Tu as tellement de code de plugin que tu est obliger de tout coller dans des espaces différents?

En quoi gérer des processus seraient moins bien ? (comme Chrome en fait ?)

"La première sécurité est la liberté"

Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.

Bientot, C avec ses info de debug va être qualifier de tourner en VM :)

"La première sécurité est la liberté"

A quoi servent les options -m32 and -m64 de GCC ?

Euh... il faut bien lui dire si tu veux compiler pour x86 ou x86-64...

Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?

Pour mettre sizeof() et non 4, dans ton code.

"La première sécurité est la liberté"

Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.

C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM et te garantisse que jamais un pointeur ira se balader n'importe où. C'est le compilo qui fait ça.

Je te dirais même que cette propriété à la con, est une pure expérience du C.

"La première sécurité est la liberté"

Cela dépend ou. Sur les micro 16 bits, les pointeurs pouvaient déjà être plus grand que int.

"La première sécurité est la liberté"

Mais honnêtement, ça doit arriver bien moins souvent qu'un free oublié en C, ou qu'un delete qui manque en C++ ?

oui mais aujourd'hui, il y a valgrind, et cela change tout.

Surtout qu'il arrive parfois qu'on ne sache pas quand exactement libérer la ressource, sauf à compter les références manuellement.

C'est souvent le problème d'une mauvaise encapsulation, non ?

"La première sécurité est la liberté"

Les risques juridiques sont bien évidemment réels, mais nous savons que ces risques existent également pour tout un tas de logiciels libres autres que Mono.

Tu dois avoir des infos que je n'ai pas. Ou alors, tu fais références aux problèmes globals des brevets logiciels.

Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.

"pourquoi utiliser une techno Microsoft alors que nous avons les notres, dans le libre ?" etc.

Quand C# est sorti, c'était vraiment je refais un Java purement MS...

Sinon, comme je l'ai dis plus bas : disons bye bye à XMLHttpRequest. Non ?

ben non, c'est standardisé aujourd'hui. Ce n'est pas un produit, c'est juste une spécification qui supporté par tout le monde (interopérable).

"La première sécurité est la liberté"

Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM.

Le C définit depuis toujours des symbole pour le link, le link dynamique, et le debug. Cela n'a rien à voir avec une VM qui traduit du bytes code !


Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.

Utilise 2 processus, c'est fait pour. En plus aujourd'hui, il y a mini 2 coeurs à disposition.


ADA propose au sein de son langage une abstraction des threads, il défini une VM.

n'importe quoi. C'est pas parce que l'on te trouve plein de contre exemple qu'il tout appelé VM ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.


La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.

C'est évident et Ada pond du code machine ! (essaye gnat)


Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.

si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.

"La première sécurité est la liberté"