IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    juillet 2017
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2017
    Messages : 11
    Points : 15
    Points
    15
    Par défaut du calme du calme
    on s'éloigne du sujet dans ce débat..

    un langage peut avoir des soucis de sécurité, mais pour ce qui est de la mémoire, le problème se situe généralement entre la chaise et le clavier..

    si un dev ne comprend pas les buffer overflows => on sait tous quoi en déduire
    si un dev ne comprend pas qu'il faut gérer tous les cas de figure en programmation, meme des attaques => bah ... tant pis

    de mon point de vue (qui vaut ce qu'il vaut, on est d'accord), avant de se dire qu'il faut changer de langages, il faut déjà maitriser les tenants et les aboutissants car des petits malins trouveront toujours un moyen de lever un exploit, meme sur des langages dits "sécurisés" dixit la NSA


    sinon assez d'accord, faire confiance à la NSA en terme de conseil .. échelon toussa ("on a vu que vous utilisiez des langages pas sécurisés, ah et d'ailleurs, il y a des bugs de votre appli, tel fichier telle ligne ")

  2. #22
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    1 582
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 1 582
    Points : 45 808
    Points
    45 808
    Par défaut Bjarne : « La sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++ »
    « La sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++ », d’après Bjarne Stroustrup
    qui réagit à une sortie de la NSA qui exclut le C++ des langages sécurisés

    Mark Russinovich de Microsoft a déclaré au troisième trimestre de l’année précédente que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA trouve désormais contradicteur et pas des moindres. Sans détour, le créateur du langage C++ déclare : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »

    En effet, Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.

    « Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

    Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.


    L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    #include <type_traits>
    #include <utility>
    #include <assert.h>
    #include <stddef.h>
    enum NoRefs {};
    enum HasMutRef {};
    enum HasRefs {};
    template <class T, typename Mode>
    class Own;
    template <class T>
    class MutRef;
    template <class T>
    class Ref;
    template <class T, typename... Args>
    inline Own<T, NoRefs> make(Args... args) {
      return Own<T, NoRefs>(std::forward<Args>(args)...);
    }
    template <class T>
    inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) {
      return Own<T, NoRefs>(std::move(own));
    }
    template <class T>
    inline Own<T, NoRefs> consume(Own<T, HasRefs> own) {
      return Own<T, NoRefs>(std::move(own));
    }
    template <class T>
    std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) {
      T* t = own.t_;
      own.t_ = nullptr;
      return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t));
    }
    template <class T>
    std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) {
      T* t = own.t_;
      own.t_ = nullptr;
      return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t));
    }
    // No refs exist.
    template <class T>
    class [[clang::trivial_abi]] Own<T, NoRefs> {
     public:
      template <typename... Args>
      Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {}
      ~Own() { delete t_; }
      Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; }
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
     private:
      friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref);
      friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own);
      friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own);
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
      Own(Own<T, HasMutRef>&& own) : t_(own.t_) {}
      Own(Own<T, HasRefs>&& own) : t_(own.t_) {}
      T* t_;
    };
    // A mut ref exists.
    template <class T>
    class [[clang::trivial_abi]] Own<T, HasMutRef> {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
     private:
      friend class Own<T, NoRefs>;
      Own(T* t) : t_(t) {}
      ~Own() {}
      T* t_;
    };
    // Non-mut refs exist.
    template <class T>
    class [[clang::trivial_abi]] Own<T, HasRefs> {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
      Ref<T> ref() { return Ref<T>(t_, &count_); }
     private:
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
      explicit Own(T* t) : t_(t) {}
      ~Own() { assert(count_ == 0u); }
      T* t_;
      uint32_t count_;
    };
    template <class T>
    class MutRef {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
      ~MutRef() = default;
      MutRef(MutRef&& other) : t_(other.t_) {}
     private:
      friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own);
      MutRef(T* t) : t_(t) {}
      T* t_;
    };
    template <class T>
    class Ref {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
      ~Ref() { --(*count_); }
      Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); }
      Ref(Ref&& other) : t_(other.t_), count_(other.count_) {}
     private:
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
      Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); }
      T* t_;
      uint32_t* count_;
    };
    MutRef<int> Borrows(MutRef<int> i) {
      (*i)++;
      return i;
    }
    TEST(Borrow, HelloWorld) {
      // Can't do this. The HasMutRefs type is not destructible outside of
      // consume()in order to have compiler check it is re-owned, but it won't
      // compile. To pass the HasMutRefs to consume() it has to be destroyed both
      // inside and outside of consume(). This is true even if trivial_abi is
      // used and only one destructor would actually run.
      Own<int, NoRefs> i = make<int>(5);
      auto& hasmut = mut(std::move(i));
      MutRef<int> ref = Borrows(std::move(hasmut.second));
      Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref));
    }

    La sortie de Bjarne Stroustrup intervient dans un contexte où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

    Après 31 ans, un deuxième langage fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

    Sources : Bjarne, Google

    Et vous ?

    Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
    Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
    Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

    Voir aussi :

    L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
    Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
    C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #23
    Membre du Club
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2013
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mai 2013
    Messages : 19
    Points : 51
    Points
    51
    Par défaut
    je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets. L'un via les constructeurs et l'autre via les implementations de traits

  4. #24
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 371
    Points : 5 694
    Points
    5 694
    Par défaut
    Citation Envoyé par Padget Voir le message
    je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets.
    Pour la gestion de la mémoire, le C++ offre la possibilité d'utiliser le RAII qui évite les double free et permet aux éventuelles fuites de mémoire de ne pas être plus fréquentes que dans un langage avec ramasse-miettes.

    Il y a des développeurs C++ qui sous-utilisent le RAII et introduisent plein de fuites de mémoire, ce qui est un problème culturel autour de l'apprentissage du C++.

    Cependant, le C++ n'empêche pas à la compilation les dandling references/pointers/iterators. Par exemple, si on garde une référence vers un élément d'un vecteur, puis que l'on fait un push_back, que ce dernier oblige de déplacer ailleurs en mémoire les éléments du vecteur, puis que l'on essaie d'accéder à ce vers quoi pointe la dandling reference, cela ne provoque pas d'erreur de compilation, contrairement à Rust. Le C++ n'a pas autant de contrôles à la compilation qu'en Rust.

    Idem pour le multithreading : le C++ ne fait pas de contrôle à la compilation contre les accès concurrents.

    Le C++ n'a pas le borrow checker de Rust. Pour les contrôles à la compilation, ces deux langages ne sont clairement pas au même niveau.

  5. #25
    Membre averti
    Profil pro
    Développeur
    Inscrit en
    octobre 2008
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : octobre 2008
    Messages : 117
    Points : 402
    Points
    402
    Par défaut
    Hebe, il va pas bien Bjarne ou quoi? Il a oublie que C++ a besoin des sanitizers pour ne meme pas arriver au niveau du borrow checker de rust?
    Bon, il defend son bout de pain apres, il perd pas le nord, mais bon de la a dire des trucs pareil je sais pas trop..

  6. #26
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 317
    Points : 3 720
    Points
    3 720
    Billets dans le blog
    12
    Par défaut
    Bjarne Stroustrup est sans conteste un immense contributeur au monde du développement informatique, mais il défend son bébé qui... conserve ses défauts.

    J'ai commencé l'informatique avec C++, touché à bien des langages, et je reconnais les qualités de Rust malgré ses défauts comme le temps de compilation et le manque de lib. Pour moi Rust est un pas en avant, il est ce que C++ a essayé d'être si C++ n'avait pas essayé de rester rétro-compatible avec C dans un premier temps, puis avec lui-même. Je vois les efforts de Herb Sutter, il essaye d'améliorer C++ avec "CppFront" mais même avec ça on n'arrive pas au niveau des exigences de Rust en terme de null-safe, memory-safe, thread-safe
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  7. #27
    Membre du Club
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2013
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mai 2013
    Messages : 19
    Points : 51
    Points
    51
    Par défaut
    Certes mais ça reste mon scalpel préféré pour faire du code 😊

  8. #28
    Membre émérite
    Profil pro
    Inscrit en
    juin 2009
    Messages
    777
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 777
    Points : 2 478
    Points
    2 478
    Par défaut
    Bah pour lui j'imagine qu'il peut vraiment coder aussi bien en C++ qu'un expert en Rust.

    Mais quid du développeur... "moyen" ? (un vrai développeur quand même)

  9. #29
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 4 506
    Points : 14 869
    Points
    14 869
    Par défaut
    C'est a rapprocher du récent document de Bjarne Stroustrup en tant que membre du groupe de direction de l'ISO C++ : https://www.open-std.org/jtc1/sc22/w...23/p2759r0.pdf

    On voit bien qu'il est pris de court par le tournant actuel de l'industrie vers une sécurisation par défaut, qu'il n'a pas du tout anticipé, et dont il a encore du mal à admettre l'importance. On voit qu'il a tendance à réduire le problème au fait que le C++ devrait mieux communiquer sur ses fonctionnalité de sécurité. Il peine à cerner ce qu'est exactement Rust et ce qu'il apporte(approximations, exemples mal choisis, ...). Après avoir passé une grande partie du document a minimiser le problème, il ébauche quand même un chemin vers une vraie sécurisation du C++, mais on voit bien qu'ils sont encore loin ne serait-ce que d'un embryon de solution consensuelle.

  10. #30
    Membre du Club
    Profil pro
    Inscrit en
    août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 56
    Points : 65
    Points
    65
    Par défaut
    Ok le borrow-checker c'est top...
    mais quid du paradigme TRAIT ?
    je trouve ca plus souple que la poo.

  11. #31
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    mai 2007
    Messages
    1 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2007
    Messages : 1 039
    Points : 2 205
    Points
    2 205
    Par défaut
    Sans attendre l'ISO et Stroustrup. La communauté C++ à la chance d'être une des plus compétentes avec des décennies d'expériences.

    Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.

    L'équipe de Clang commence déjà a proposer des solutions.
    https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377
    Homer J. Simpson


  12. #32
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 4 506
    Points : 14 869
    Points
    14 869
    Par défaut
    Citation Envoyé par foxzoolm Voir le message
    Ok le borrow-checker c'est top...
    mais quid du paradigme TRAIT ?
    je trouve ca plus souple que la poo.
    C'est vrai que les traits sont une fonctionnalité indiscutablement au cœur de Rust tout aussi importante sinon plus que le borrow checker. Je dirais aussi que les enum sont au moins aussi importante. Mais le sujet c'est la sécurité, et pour le coup, ça n'est ni les trait ni les enums qui font la sécurisation du Rust.
    Ce qui fait sa sécurisation mémoire comparé au C++, c'est principalement le borrow checker et des choix par défaut sécurisés (initialisation obligatoire des variables, contrôles de dépassement, ...)

    Citation Envoyé par Astraya Voir le message
    Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.
    C'est pas les initiatives qui manquent pour améliorer la sécurité du C++, mais la difficulté c'est de faire quelque chose qui, à la fois :
    • soit vraiment efficace
    • s’intègre bien a la syntaxe du langage
    • marche bien avec la base de code existante
    • est acceptable pour des utilisateurs qui n'ont jamais eu de contraintes fortes jusqu’à présent

    La plupart des initiatives que j'ai vu pèchent lourdement sur un ou plusieurs de ces points.
    L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.

    Citation Envoyé par Astraya Voir le message
    L'équipe de Clang commence déjà a proposer des solutions.
    https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377
    C'est intéressant ça. Pour le coup ça a l'air complétement calqué sur le système des lifetimes de Rust. Reste a voir ce que ça pourra donner en pratique.

  13. #33
    Membre émérite
    Profil pro
    Inscrit en
    juin 2009
    Messages
    777
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 777
    Points : 2 478
    Points
    2 478
    Par défaut
    Citation Envoyé par Uther Voir le message
    L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.
    .
    Ca me fait penser au passage de Python 2 à Python 3 ou en tout cas un exemple de ce qui peut arriver sur une évolution de langage "brutale".

Discussions similaires

  1. Parts de marchés des langages de programmation
    Par Marc Lussac dans le forum Langages de programmation
    Réponses: 51
    Dernier message: 21/05/2013, 14h51
  2. Index TIOBE du classement des langages de programmation
    Par Gordon Fowler dans le forum Actualités
    Réponses: 564
    Dernier message: 13/01/2013, 19h51
  3. Passer des paramètres à un programme
    Par Cravis dans le forum VB 6 et antérieur
    Réponses: 4
    Dernier message: 08/11/2007, 15h32
  4. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 03/04/2006, 00h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo