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

Débats sur le développement - Le Best Of Discussion :

Les détracteurs du Rust s’unissent autour de l’initiative Fil-C : Un implémentation sécurisée du C


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    2 110
    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 : 2 110
    Points : 56 813
    Points
    56 813
    Par défaut Les détracteurs du Rust s’unissent autour de l’initiative Fil-C : Un implémentation sécurisée du C
    Les détracteurs du Rust s’unissent autour de l’initiative Fil-C : Une implémentation sécurisée des langages C et C++
    Destinée à redonner au langage C sa grandeur

    Le langage C est de plus en plus sujet à controverse comme en témoigne la situation tendue dans la communauté de développement du noyau Linux : les principaux mainteneurs sont des habitués du langage C et refusent de porter le code existant en C ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. En toile de fond, c’est la question de savoir si le langage C a besoin d’un remplaçant dans la filière de la programmation système qui est au centre des débats. C’est la raison de l’apparition d’implémentation dites sécurisées du langage C comme Fil-C.

    « Les langages de programmation C et C++ sont merveilleux. Il existe une tonne de codes écrits dans ces deux langages. Mais le C et le C++ sont des langages peu sûrs. De simples erreurs de logique peuvent amener un attaquant à contrôler la zone mémoire un pointeur et ce qui y est écrit, ce qui ouvre la voie à une exploitation facile. Beaucoup d'autres langages (Rust, Java, etc.) n'ont pas ce problème ! Mais j'aime le C. Et j'aime presque autant le C++. J'ai grandi avec eux. C'est une telle joie pour moi de d'utiliser les deux ! C'est pourquoi, pendant mon temps libre, j'ai décidé de créer mes propres langages C et C++ à mémoire sécurisée. Il s'agit d'un projet personnel et d'une expression de mon amour pour le C. Fil-C introduit la sécurité de la mémoire au cœur du C et du C++ », souligne Filip Pizlo de Epic Games.

    « Le projet vise une compatibilité à 100 % avec C et C++. Il suffit de compiler son code avec le compilateur pour obtenir du code sécurisé », d’après Pizlo. Ce dernier reconnaît néanmoins que « le principal obstacle à l'utilisation de Fil-C en production est la vitesse. Fil-C est actuellement environ 1,5 à 5 fois plus lent que le C traditionnel. »

    Nom : 0.png
Affichages : 84021
Taille : 354,5 Ko

    L’initiative fait surface dans un contexte de multiplications des appels au passage à des langages de programmation dits sécurisés et Rust s’impose au point d’être adopté pour lé développement du noyau Linux

    Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux 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 du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

    En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

    De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

    Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

    Source : GitHub du projet

    Et vous ?

    Que pensez-vous de cette multiplication d’implémentations dites sécurisées du langage C ?
    Pourquoi le langage C pourrait encore avoir de longues années devant lui ? Simple résistance au changement ?
    Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
    Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?


    Voir aussi :

    Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

    Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

    Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

    Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expert
    Profil pro
    programmeur du dimanche
    Inscrit en
    Novembre 2003
    Messages
    895
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : programmeur du dimanche
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2003
    Messages : 895
    Points : 3 838
    Points
    3 838
    Par défaut
    C'est une compilation avec des bound checks et un garbage collector. Ça va pas plaire à tout le monde. En plus il faut modifier un peu les sources.

  3. #3
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    194
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 194
    Points : 155
    Points
    155
    Par défaut
    A toujours être assister on perd en compétence ! çà c'est un paradigme

  4. #4
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2024
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2024
    Messages : 52
    Points : 193
    Points
    193
    Par défaut
    Que pensez-vous de cette multiplication d’implémentations dites sécurisées du langage C ?
    Je ne suis pas contre, on a plusieurs idée explorée tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment sûr de ça) ajouter une notion d'ownership avec Zig. Peut-être que qu'une idée novatrice s'imposera, ou peut être que l'on aura un énième langage. La plus grosse contrainte est la compatibilité avec l'existant et je ne pense pas qu'il y a de solution miracle.

    Pourquoi le langage C pourrait encore avoir de longues années devant lui ? Simple résistance au changement ?
    Tout simplement parce qu'il y a une énorme base de code en C, tout transcripter en un langage à mémoire sûre demandera beaucoup de temps donc d'argent. Ajoutons aussi que la simplicité de C permet aussi d'écrire "facilement" un compilateur pour une plateforme personnalisée. C ne nous quittera pas de sitôt n'en déplaise à ses détracteurs.

    Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
    Je dirai que oui, les cyberattaques sont de plus en plus sophistiquées, une petite erreur simple peut permettre un contrôle à distance et garantir qu'une énorme base de code sera 100% safe demande un temps monstrueux (amusez à faire de la preuve formelle avec coq sur absolument tout un programme, je suis presque sûr que ça sera plus long que de réécrire le code en un langage à mémoire sûre). On peut aussi compter le temps perdu pour débugguer un problème mémoire.
    Ce n'est que mon avis, mais il faut un langage à mémoire sûr qui ne sacrifie pas significativement les performances. D'une part, cela garanti une absence de type de faille de facto, d'autre part, cela améliorera la productivité et permettra de se focaliser plus sur les aspects de logique et moins sur de la technique.

    Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
    Est-ce de la faute du développeur de ne pas avoir prévu tous les cas possible et impossible ? Est-ce de la faute du manager d'avoir mit une deadline qui a réduit les campagnes de test ? Est-ce la faute de ces grandes entreprises qui font des bénéfices énormes sur les communautés libre et open source sans pour autant investir dans celle-ci pour améliorer le code ? Est-ce la faute du langage qui permet de se tire une balle dans le pied ?
    La réponse est: un langage, c'est un choix technique et comme tout choix technique il y a des avantages et des inconvénients. Choisir le C c'est avoir de très bonne performance au prix de devoir gérer la mémoire soit même et les risque accrus d'un plantage ou de faille de sécurité. Je ne blâmerais ni les dev, ni le langage si leur programme plante tous les vendredi 13, soir de pleine lune lorsque tous les astres du systèmes solaires sont alignés.

  5. #5
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2024
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2024
    Messages : 52
    Points : 193
    Points
    193
    Par défaut
    Citation Envoyé par vivid Voir le message
    A toujours être assister on perd en compétence ! çà c'est un paradigme
    [Troll]
    Tu as raison, les IDE avec leurs suggestions automatiques et leur autres fioritures, les smart pointer, les class, les struct, les bibliothèques, les compilateurs et les éditeurs de lien... Que d'éléments qui nous obscurcissent de la vrai connaissance de la programmation ! Les vrais dev, eux ils font tout en assembleur et leur programmes marchent sans problème quelque soit l'ordinateur ou le temps
    [/Troll]

    Il faut savoir où mettre son cheval de bataille. Le temps passer à s'assurer que toutes les possibilités soient correctement traiter est de la productivité de perdu. Si l'on peut gagner en productivité et en stabilité tout en conservant les performances, pourquoi devrions refuser d'être assister ? Pour la beauté du geste ?
    Attention, je ne dis pas qu'il ne faut pas savoir comment ça marche derrière, rien n'est magique et l'obscurantisme mènent à la dépendance. Je dis juste que rejeter toute assistance est idiot. Si le borrow checker de Rust me dit qu'il y a un risque d'un double emprunt, c'est pas lui qui à mal compris mon code, c'est moi qui n'a pas vu le cas où ça pourrait si produire. L'humain aussi assidu puisse t-il être ne sera jamais infaillible. Avoir l'assistance d'un programme l'aide à éviter des erreurs

  6. #6
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    305
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 305
    Points : 726
    Points
    726
    Par défaut
    Citation Envoyé par vivid Voir le message
    A toujours être assister on perd en compétence ! çà c'est un paradigme
    Rassure toi, les règles d'emprunt, et les manières de faire avec de Rust nécessitent des compétences. Même si le compilateur est assez didactique dans son assistance.

    Citation Envoyé par NotABread Voir le message
    Je ne suis pas contre, on a plusieurs idée explorée tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment sûr de ça) ajouter une notion d'ownership avec Zig. Peut-être que qu'une idée novatrice s'imposera, ou peut être que l'on aura un énième langage. La plus grosse contrainte est la compatibilité avec l'existant et je ne pense pas qu'il y a de solution miracle.
    Mais est-ce vraiment nécessaire de multiplier à outrance les langages ? L'intérêt d'un langage est aujourd'hui autant dans les qualités intrinsèques que dans l'écosystème autour (à commencer pour le côté batteries included). Le côté révélateur est marqué par les gestionnaires de packages qui permettent une fluidité dans l'accès à cet écosystème (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).

    Actuellement, on a des langages évolués, mais néanmoins avec des implémentations proches du matériels (Rust, Ada, Zig, D...). Ada est peut-être un des rares langages avec des types entiers bornés (comme range 1..10). L'avantage est que si une variable a ce type, inutile de tester les limites d'un tableaux de type array (range 1..10) of Integer. Un for I in Tableau'Range loop Tableau(I) := Tableau(I)*2; end loop; peut être compilé sans aucune vérification de bornes (sauf le *2... si on dépasse la capacité des Integer !! NB: Il y a des types sans vérifications de bornes), mais aussi sans aucun risque de sécurité. Par ailleurs, il existe des langages moins proches du matériels utilisés aussi dans des applications similaires (le projet MirageOS vise à proposer un Unikernel en OCaml).

    Quand à ajouter à C/C++ un GC et des bound check, c'est peut-être ce qui est fait avec C# dans une certaine mesure. (Même si l'arithmétique des pointeurs y est autorisé uniquement pour des blocs unsafe).

  7. #7
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2024
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2024
    Messages : 52
    Points : 193
    Points
    193
    Par défaut
    Citation Envoyé par floyer Voir le message
    Mais est-ce vraiment nécessaire de multiplier à outrance les langages ? L'intérêt d'un langage est aujourd'hui autant dans les qualités intrinsèques que dans l'écosystème autour (à commencer pour le côté batteries included). Le côté révélateur est marqué par les gestionnaires de packages qui permettent une fluidité dans l'accès à cet écosystème (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).
    J'ai envie de dire oui et non. Non car multiplier le nombre de langage disperse des ressources qui pourrait être mutualiser pour faire un bon langage plutôt que 20 moyen ou expérimentale. Oui car ces nouveaux langages ou extensions de langage cherche à répondre à un problème qui n'a pas de solution satisfaisante (ou pas totalement), et c'est source d'innovation. Certaines initiatives cherchent même à conserver l'accès à l'écosystème déjà établi (il me semble que les travaux visant à faire un C++ sûr ont toujours garder une compatibilité avec le C++ standard).

  8. #8
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    305
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 305
    Points : 726
    Points
    726
    Par défaut
    Oui… quand je vois que Java a mis 8 ans (1996-2004) pour intégrer les génériques. Avec C# c’est arrivé plus tard encore (2005 mais leur V1 date de 2003)… fonctionnalités de ML (typage Hindley-Milner en 1978), reprise dans Ada (1983)… ainsi, je veux bien croire et espérer que chaque language essaye de se démarquer en ajoutant un truc en plus, mais à réinventer la roue, on peine parfois à se mettre à l’état de l’art pour lequel la barre est de plus en plus haute. Sauf à avoir une bonne expertise (ce qui me semble le cas de ceux qui ont fait Rust).

    Ça dépend aussi de la portée du langage. Haskell avec son côté purement fonctionnel et paresseux se démarque franchement et ouvre une voie de recherche.

    Après, il y a des langages (et implémentations) construites pour utiliser leur écosystème (Ada avec C qui a des pragma dédiés et standards, les langages des VM .Net et JVM…). D’autres nécessitent des bindings en C (JNI avec JVM…).

    Pour C++, une bibliothèque STL alternative est peut-être le plus simple (de mémoire, Stroutstrup semblait dans un de ses livres mettre en avant les vecteurs que les tableaux).

    Par ailleurs, supprimer l’arithmétique des pointeurs au C++, mettre un GC et cela commence à ressembler à C#.

  9. #9
    Membre régulier

    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2023
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Octobre 2023
    Messages : 60
    Points : 97
    Points
    97
    Par défaut
    J'ai écrit plusieurs applications en C et en C++ qui ont passé tous les test de vérifications avec succès. Aucune fuite et toute la salade avancées par les amateurs de Rust. Mais comme ces applications sont écrites en C et C++ et non en Rust elles sont donc dangereuses quoi qu'elles fassent. L'aspect sécuritaire du Rust n'est qu'un détail qui ne peut pas remplacer le C ou le C++. D'ailleurs pourquoi pas Ada ou Pascal ? Là aussi ce sont des langages pourris comme le C et le C++ ?

  10. #10
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    305
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 305
    Points : 726
    Points
    726
    Par défaut
    Le Pascal a tout de même beaucoup de limitations qui sont compensés dans l’implémentation de Delphi qui supporte entre autres l’objet et les génériques. On est alors assez loin du langage de Niklaus Wirth. C’est presque un Ada avec une autre syntaxe un peu proche, même s’il reste beaucoup de différences.

    Ada est très novateur avec les tâches/rendez-vous et génériques dès 1983, puis l’objet en 1995. D’ailleurs les tableaux Delphi ressemblent aux tableaux Ada en ce sens qu’il incluent leurs bornes (on peut écrire High(Array) pour obtenir la borne max, comme un Array’Last en Ada. C’est une différence majeure avec C/C++ (les tableaux passés en paramètre sont de simples pointeurs qui obligent à passer en plus des tailles comme avec strncmp, strncpy… évidemment en C++, on pourrait préférer les vector)

    Le côté embêtant en Ada est la gestion des caractères… pour avoir un tableau de chaînes de caractères de tailles différentes, il faut les convertir en Unbounded_String ce qui alourdi les choses. C’est plus pratique en Delphi.

    Là où Rust se distingue de Delphi et Ada est l’introduction de la programmation fonctionnelle. Typiquement : words.iter().map(|&s| s.to_uppercase()).collect() cela peut être assez puissant. C’est le genre de chose introduite avec les stream Java 8. Bon Delphi supporte les fonctions anonymes (lambda fonctions) mais c’est plus lourd et il ne me semble pas qu’il y ait les fonctions usuelles (map, filter…) même si on peut les réimplémenter. Rust désalloue automatiquement les objets du tas, là où c’est manuel en Delphi et Ada. Rust et probablement Delphi supportent les closures, pas Ada.

  11. #11
    Membre régulier

    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2023
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Octobre 2023
    Messages : 60
    Points : 97
    Points
    97
    Par défaut
    Concernant cette obsession des fuites et accès mémoire il faut tenir compte du fait que les langages ne font qu'emprunter de la mémoire au système d'exploitation. Et de plus ces systèmes d'exploitation sont dépendants de l'architecture matérielle de la mémoire. A ces conditions on outil malveillant peut accéder à la mémoire de la machine ce qui n'a rien à voir avec Rust ou C. En C il faut être vigilant dans l'écriture des programmes ce n'est pas impossible ni condamné au manque de sécurité. Ce qu'apporte Rust aux autres langages est un détail qui ne peut pas effacer les autres fonctionnalités des autres langages. De plus ce qui est assez étonnant c'est le haro sur le C et la bénédiction du Python qui pourtant est implémenté en C. Python c'est bien mais le C alors là le scandale. Rien de meilleur que des bibliothèques écrites selon l'API en C de Python pour booster les applications Python. Mais c'est vrai que le C est déroutant pour ceux qui n'arrivent à compter jusqu'à 10 en partant de 0 à 9.

  12. #12
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    305
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 305
    Points : 726
    Points
    726
    Par défaut
    Pourquoi parler d’obsession alors que le problème des accès mémoire est une cause importante de CVE ? (Cf https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33)

    Et si, cela a voir avec le langage. En Rust accéder au 10ème éléments d’un tableau de 5 cause une exception alors qu’en C, tu auras des effets de bord (en lecture, l’attaquant peut obtenir des informations confidentielles, en écriture, provoquer un comportement inattendu). Le dernier bug de Crowdstrike est un exemple.
    Je ne vois pas où tu veux en venir avec l’OS et la mémoire physique. La question n’est pas de savoir si on accède à de la mémoire physique in fine (forcément…) mais si on accède aux zones prévues. Si tu as un tampon de 64 caractères pour un mot de passe, une implémentation naïve écrasera de manière inattendue les variables après dès que tu envoies un mot de passe plus long.

    Et oui, comme la plupart des programmes complexe Python n’est pas exempt de bug, mais ce logiciel est plus éprouvé que beaucoup de projet (plus de contributeurs). Si bien que tu peux tout de même gagner à utiliser Python là où il est adéquat. Nb : en Python, range(10) compte aussi de 0 à 9… ce sont plutôt des langage comme Ada ou Pascal où tu comptes jusqu’à la borne sup incluse… (le mieux étant les langages fonctionnels où des fonctions comme map te dispensent de compter. Python permet d’écrire [x*2 for x in l], ce qui dispense d’expliciter une boucle sur les indices de la liste l. En Ada, on écrirait la boucle comme for i in Table’Range loop … ce qui laisse peu de risque d’erreur. Pareil en Rust : for &x in tableau.iter() { …}).

    Et sinon, Rust est aussi conçu pour limiter les bug liés à la programmation concurrente (race condition…)

Discussions similaires

  1. Réponses: 22
    Dernier message: 27/11/2024, 08h29
  2. Réponses: 2
    Dernier message: 08/04/2011, 16h53
  3. Supprimer les pointillés autour d'un lien
    Par grinder59 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 10
    Dernier message: 28/06/2009, 20h54
  4. [XSL] Sélectionner les éléments qui n'ont pas un certain fils
    Par lebechen dans le forum XSL/XSLT/XPATH
    Réponses: 3
    Dernier message: 05/07/2006, 18h54
  5. tourner autour d'1 objet ds ttes les directions
    Par Mat 74 dans le forum OpenGL
    Réponses: 2
    Dernier message: 20/10/2004, 21h48

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