Discussion :

[Patrick Ruiz]

Linus Torvalds se prépare à faire passer le noyau Linux au C moderne (C11)
Dans un contexte où le langage Rust apparaît de plus en plus comme candidat idéal à la mise au rebut du langage C

15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : 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. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de constat que vient sa décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. La nouvelle tombe dans un contexte où le langage Rust apparaît comme candidat idéal à la mise au rebut du C.

Arnd Bergmann, développeur du noyau Linux, est d’avis que la manœuvre est réalisable. L’idée est bonne selon ce dernier étant donné que C99 n'a jamais été très populaire et que C11 a introduit le support standardisé du multithreading et a rendu le langage un peu plus sûr. GCC 5.1 est disponible depuis 2015 avec le support complet des standards C++ 11 et C++14. Cet état de choses ouvre la possibilité de voir la version 5.18 du noyau sortir avec prise en charge du C moderne.

La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et 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 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é.

Et vous ?

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
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 ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

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

[KiLVaiDeN]

Je trouve le débat sur la réécriture du noyau Linux en Rust un peu trop "optimiste". Rust n'est pas aussi mature en terme d'options de compilation, de vitesse de compilation, et sa "sécurité" est un frein plus qu'une feature pour du code kernel où il est nécessaire de faire des opérations dites "unsafe". Il faut voir que le C est le langage le plus proche de la machine, à part l'assembleur bien entendu, et il est choisi pour sa portabilité. Si il existait un assembleur aussi portable que du C, le noyau serait probablement écrit dans cet assembleur. Car le but c'est d'avoir un code rapide et efficace, permettant d'exploiter un maximum de possibilités des machines visées. Le fait que chaque CPU a son propre jeu d'instruction fait que le C est une bonne virtualisation, et c'est le rôle des compilateurs de produire le code optimisé pour la machine cible. Et C, de ce côté là, est doté d'un arsenal que Rust n'a pas encore.

Donc oui, Rust a des avantages sur C pour la programmation de tous les jours, par les protections qu'il apporte notamment qui évite certains bugs, mais Rust est encore bien moins équipé en termes d'outils que C pour la compilation de noyau. J'ai l'impression que pas mal de personnes se disent que Rust est forcément "mieux" que C parce qu'il est plus récent et moderne, mais la finalité c'est de produire un code optimisé et correcte, ce qui est possible en C, preuve en est justement le kernel Linux qui est utilisé par des millions de machines tous les jours et qui fournit très peu de bugs. (précision là-dessus, quand j'entend "très peu de bugs" veuillez comprendre "en moyenne pour un code aussi utilisé et déployé")

Le C a encore de longues années devant lui pour ces raisons. Et même si un jour Rust devenait aussi équipé que C en termes d'outils, même si son mode "unsafe" était aussi accessible que celui du C, il faudrait une raison valable pour entamer une telle réécriture, et pour l'instant j'ai du mal à en voir une, car si la raison évoquée est d'avoir accès à un langage plus "sûr", qui serait donc sensé compenser les erreurs des programmeurs, je trouve cette raison regrettable. La seule raison serait pour moi d'avoir un code tout aussi robuste et optimisé, tout en fournissant accès à des structures de données et un langage plus évolué, là oui, on pourrait alors imaginer avoir un code Linux plus "parlant", et ce serait une bien meilleure raison.

[chrtophe]

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Je pense que oui.

De ce que j'ai compris de Rust, il met par défaut certains gardes fous avec par exemple l'immuabilité d'une variable (une variable ne peut être affectée qu'une fois sans le mot-clé mut pour mutable). si ça emmerde un développeur et qu'il déroge par défaut à ce type de garde-fou par convenance, donc une mauvaise pratique, on en revient au même prob. qu'avec le C.

De ce que j'ai compris, Les blocs de codes unsafe donnent des "superpouvoirs", peut-être nécessaire pour faire de la programmation système, et on en revient au prob. du C.

Mais peut-être qu'avec Rust, un développeur débutant pourra peut-être générer du code moins dangereux, en dehors de code bas niveau qui n'est en général pas fait par un débutant.

[gzii69]

D'un côté je suis d'accord que le Rust doit encore mûrir, et que tout réécrire n'est sans doute pas possible (c'est plutôt quelque-chose qui se ferait petit à petit avec de nouvelles fonctionnalités).

De l'autre dire qu'il suffit de ne pas faire d'erreur ? On en fait tous, une faute d'inattention, un cas auquel on n'aurait pas pensé. Et réfléchir une nième fois parce que le compilateur refuse une façon de faire qui pourrait être unsafe, c'est pas forcément mauvais (surtout quand les messages sont clairs).
C'est comme pour les tests. Sont ils inutiles ? Faut-il considérer qu'ils ne sont valables que pour les débutants ?

Et en plus de ce que j'ai pu tester, j'obtiens des perfs vraiment équivalentes à celles du C, avec une grande stabilité en multithread et utilisation intensive avec plein de connexions et mémoire partagée (une plus grande stabilité que celle que j'aurais obtenu en C surtout avec un code si jeune). Et je suis plutôt débutant en Rust.
Bref à mon avis non le C ne va pas disparaitre comme ça, c'est sûr, mais c'est sympa de s'intéresser au Rust et de le tester.
Et plus si affinités (souvent il y en a, on n'est pas si éloignés de la machine par rapport au C si on en a fait).

[Uther]

Je trouve le débat sur la réécriture du noyau Linux en Rust un peu trop "optimiste".

C'est surtout qu'il n'y a pas de débat. Il n'y a aucun plan qui prévoit de réécrire le noyau Linux en Rust. La seule chose qui est prévue, c'est de permettre d'écrire des modules (en gros des drivers) en Rust.

Rust n'est pas aussi mature en terme d'options de compilation, de vitesse de compilation, et sa "sécurité" est un frein plus qu'une feature pour du code kernel où il est nécessaire de faire des opérations dites "unsafe". Il faut voir que le C est le langage le plus proche de la machine, à part l'assembleur bien entendu, et il est choisi pour sa portabilité.

Au niveau de la vitesse de compilation, c'est vrai que le Rust est plus lent que le C, mais dans le cadre du développement d'un noyau, je ne pense pas que ça soit le plus gros problème.
Par contre, le compilateur Rust se base sur le backend LLVM qui sert de base à clang. Il a donc quasiment les mêmes options de compilation que le C ou C++.
Enfin, le coté sécurité de Rust ne pose pas de problème pour le bas niveau, au contraire. Rust permet de faire des blocs unsafe pour isoler les sections qui ont réellement besoin de faire des accès directs au matériel tout en gardant une grosse partie du code safe. Ça reste un gros avantage comparé a C qui est potentiellement dangereux partout.

Si il existait un assembleur aussi portable que du C, le noyau serait probablement écrit dans cet assembleur.

Ça n'a pas de sens de parler d'assembleur portable. L'assembleur est par définition l'inverse du langage portable : c'est juste une représentation textuelle du code machine. En fait il faudrait parler des langages d'assemblage, vu qu'il y en a au moins un différent pour chaque architecture, et en fait, même sur une même architecture, il peut y avoir plusieurs syntaxes différentes.
De plus même s'il n'existait qu'une seule architecture et un seul langage d'assemblage, le kernel ne serait probablement pas codé avec. L'assembleur est langage un langage bien trop complexe et verbeux pour être pratique a utiliser de manière généralisée. Un bon langage avec un compilateur efficace, de la structuration des données, une bonne lisibilité, ... ça offre de gros avantages, particulièrement en matière de maintenabilité, ce qui est aussi un point crucial pour un kernel.

Car le but c'est d'avoir un code rapide et efficace, permettant d'exploiter un maximum de possibilités des machines visées. Le fait que chaque CPU a son propre jeu d'instruction fait que le C est une bonne virtualisation, et c'est le rôle des compilateurs de produire le code optimisé pour la machine cible. Et C, de ce côté là, est doté d'un arsenal que Rust n'a pas encore.

Rust a, à peu près, le même arsenal que le C vu qu'il s'appuie actuellement sur LLVM, un des meilleurs backend de compilateur qui sert de notamment de base au compilateur C clang. Le code qu'il génère est généralement au même niveau de performance que du code C similaire. La seule limite est que LLVM gère mois d'architectures que GCC, donc Rust est plus limité sur ce point. Mais les principales architectures actuelles (x86, x86_64, ARM, ARM64, mips, powerpc, riscv,...) sont quand même gérées, et ça devrait encore s'améliorer avec l'arrivée prévue du backend GCC.

J'ai l'impression que pas mal de personnes se disent que Rust est forcément "mieux" que C parce qu'il est plus récent et moderne, mais la finalité c'est de produire un code optimisé et correcte, ce qui est possible en C, preuve en est justement le kernel Linux qui est utilisé par des millions de machines tous les jours et qui fournit très peu de bugs. (précision là-dessus, quand j'entend "très peu de bugs" veuillez comprendre "en moyenne pour un code aussi utilisé et déployé")

Vu qu'il y a pas de point de comparaison, ça n'a pas vraiment de sens de dire que le langage C fournit très peu de bugs.

Le C a encore de longues années devant lui pour ces raisons.

C a de longes années devant lui, mais certainement pas pour ces raisons. Il a de bonnes années devant lui car c'est une référence dans le bas niveau et qu'il est présent partout. On ne va pas réécrire un code qui fonctionne en un autre langage sans de très bonnes raisons et la sécurité supplémentaire, n'est généralement pas un argument suffisant. Et même si tout le monde était convaincu qu'il faut d'urgence faire disparaitre le C de partout , ça prendrait quand même des dizaines d'années de le remplacer totalement.

Et même si un jour Rust devenait aussi équipé que C en termes d'outils, même si son mode "unsafe" était aussi accessible que celui du C, il faudrait une raison valable pour entamer une telle réécriture, et pour l'instant j'ai du mal à en voir une, car si la raison évoquée est d'avoir accès à un langage plus "sûr", qui serait donc sensé compenser les erreurs des programmeurs, je trouve cette raison regrettable. La seule raison serait pour moi d'avoir un code tout aussi robuste et optimisé, tout en fournissant accès à des structures de données et un langage plus évolué, là oui, on pourrait alors imaginer avoir un code Linux plus "parlant", et ce serait une bien meilleure raison.

En soit les fonctionnalité unsafe de Rust sont tout aussi utilisable que le C. Elle sont plus verbeuses a utiliser, mais c'est voulu : les opérations "unsafe" doivent être explicites pour être sur qu'on ne les utilise pas par inadvertance comme malheureusement bien souvent en C.
Et Rust ne se limite bien sur pas à la sécurité. Le fait d'offrir un langage évolué avec entre autre des structures de données plus avancés, fait bien entendu partie des raisons essentielles d'utiliser Rust.

De ce que j'ai compris, Les blocs de codes unsafe donnent des "superpouvoirs", peut-être nécessaire pour faire de la programmation système, et on en revient au prob. du C.

Mais peut-être qu'avec Rust, un développeur débutant pourra peut-être générer du code moins dangereux, en dehors de code bas niveau qui n'est en général pas fait par un débutant.

La grosse différence, c'est que Rust est safe par défaut alors que C est unsafe par défaut. En Rust on ne peut pas faire d'opération "unsafe" par inadvertance, alors qu'en C ça finit fatalement par arriver, même aux développeurs chevronnés. Certes quand on utilise un bloc unsafe, on met la sécurité du code en jeu, mais le principe de faire ça dans un bloc, c'est que le code à risque est bien contenu dans des sections réduites, auxquelles on sait qu'il faudra porter une attention particulière. Elles sont clairement identifiées et donc bien plus faciles à vérifier.

[Madmac]

Je trouve le débat sur la réécriture du noyau Linux en Rust un peu trop "optimiste". Rust n'est pas aussi mature en terme d'options de compilation, de vitesse de compilation, et sa "sécurité" est un frein plus qu'une feature pour du code kernel où il est nécessaire de faire des opérations dites "unsafe".

Peu importe la maturité, les contraintes du langage pour assurer la sécurité deviennent une camisole de force. Par exemple, le goto est considéré un sacrilège pour la plupart des enseignants. Mais utilisé intelligemment, il peut servir à forcer le compilateur à produire du code semblable à des boucles optimisés en langage machine. Autre exemple, la création de code réentrant. Sans un truc semblable au goto, c'est à peu prêt impossible à fabriquer.

[chrtophe]

code réentrant avec goto ? comment tu libère l'espace sur la pile pour les variables de ta fonction réentrante si tu en sors avec goto ?

Je suis pas spécialiste développeur mais le seul usage pertinent à l'utilisation de goto est de sortir rapidement de boucles imbriquées. Mais je pense que le compilateur sera tout aussi capable de le faire efficacement sans goto.

Mal utilisé, tu crées un code spaghetti.

Pour en revenir à Rust, si 90% du code d'un pilote est en mode unsafe (par obligation ou convenance du développeur), il n'y a pas plus trop d’aventage à l'utiliser.

[Uther]

Pour en revenir à Rust, si 90% du code d'un pilote est en mode unsafe (par obligation ou convenance du développeur), il n'y a pas plus trop d’aventage à l'utiliser.

Si c'était le cas en effet Rust perdrait son intérêt, mais la pratique a démontré que même le code des applications les plus dépendantes du système, comme les OS ou les drivers, reste en très grande majorité constitué de code "safe".
En fait les seul projets qui sont majoritairement constitués de code unsafe, c'est les wrapper pour les bibliothèques écrites en un autre langage vu que le compilateur Rust ne peut pas garantir lui même leur sécurité.

[SofEvans]

code réentrant avec goto ? comment tu libère l'espace sur la pile pour les variables de ta fonction réentrante si tu en sors avec goto ?

Je ne sais pas si j'ai bien compris, mais j'ai l'impression que tu confonds "goto" et "setjmp".
goto ne permet que de faire un saut local à la fonction, donc toutes les variables de la pile seront nettoyées.

Je suis pas spécialiste développeur mais le seul usage pertinent à l'utilisation de goto est de sortir rapidement de boucles imbriquées.

Ah je dirais que non ^^
Pour ma part, le seul usage pertinent, c'est de faire une sorte de gestion d'exception :

Code C :

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
bool MyFunction(void)
{
    char *logPathfile = NULL;
    FILE *logFile = NULL;
    char *msg = NULL;
    bool returnValue = false;
 
    logPathfile = malloc(...);
    if (!logPathfile) {
        // Message erreur
        goto END_FUNCTION;
    }
 
    logFile = fopen(logPathfile, "w");
    if (!logFile) {
        // Message erreur
        goto END_FUNCTION;
    }
 
    msg = malloc(...);
    if (!msg) {
        // Message erreur
        goto END_FUNCTION;
    }
 
 
 
    /* .. le reste du code, avec possiblement d autres tests */
 
 
 
 
    // Fin de la fonction
    returnValue = true;
 
    /* GOTO */END_FUNCTION:
    free(logPathfile);
    if (logFile) {
        fclose(logFile);
    }
    free(msg);
 
    return returnValue;
}

Ainsi, de cette manière, tu peux être assuré de ne pas faire de fuite de mémoire quelque soit l'endroit où le code échoue, et l'ajout d'autres variables à nettoyer se fait simplement, même si la fonction est longue.

Le fait de sortir d'une double boucle, c'est vrai que c'est pratique, mais c'est une pente vraiment glissante.
En théorie, il vaut mieux mettre la boucle interieur dans une fonction et faire un break dans la première boucle si la fonction retourne un code erreur.
Mais bon, ca c'est la théorie.

[onilink_]

Si il existait un assembleur aussi portable que du C, le noyau serait probablement écrit dans cet assembleur.

Y a l'IR LLVM qui est assez proche de ça. Mais les compilateurs font presque toujours un meilleur travail que les devs pour produire de l'assembleur pour des architectures modernes. Sans parler de la relecture du code, donc la maintenabilité, la productivité etc...

Je pense que l'assembleur plus rapide qu'un langage "haut niveau" ce n'est juste plus d'actualité.
C'était vrai a l'époque ou les CPU étaient tellement "basiques" et les ressources tellement limitées qu'en fait il était difficilement envisageable d'écrire en autre chose que l'assembleur de l'architecture visée.

Mais maintenant nos CPU sont tellement complexes qu'on ne peut pas prendre en compte toutes les optimisations possibles.

[Uther]

Y a l'IR LLVM qui est assez proche de ça. Mais les compilateurs font presque toujours un meilleur travail que les devs pour produire de l'assembleur pour des architectures modernes. Sans parler de la relecture du code, donc la maintenabilité, la productivité etc...

Le LLVM IR s'en rapproche en effet, même s'il n'est pas si portable que ça. Techniquement il n'est plutôt conçu que comme une représentation intermédiaire dans une chaine de compilation que comme un langage indépendant. Ce qui fait le plus office de langage de bas niveau portable de nos jours, je dirais que c'est plutôt le WebAssembly.

Je pense que l'assembleur plus rapide qu'un langage "haut niveau" ce n'est juste plus d'actualité.
C'était vrai a l'époque ou les CPU étaient tellement "basiques" et les ressources tellement limitées qu'en fait il était difficilement envisageable d'écrire en autre chose que l'assembleur de l'architecture visée. Mais maintenant nos CPU sont tellement complexes qu'on ne peut pas prendre en compte toutes les optimisations possibles.

Je dirais que comme langage principal d'un gros projet, en effet, ça n'est plus d'actualité. Il reste cependant potentiellement utile pour des micro-optimisations sur des points chauds ou pour faire appel a des fonctionnalités CPU systèmes quand on programme un OS.

[JPLAROCHE]

De toute façon beaucoup de mots, et des divergences à qui sera le meilleur, il faut quand même se dire que ceux qui écrivent « Linux » lisent et relisent, ce n'est pas n'importe quoi. Donc j'ai confiance. En plus il y a les tests, le contrôle qualité, et finalement le passage en production... Quand on parle d'erreur à ce niveau-là ???? (surtout remettre les choses dans leurs contextes)

Non j'ai confiance d'ailleurs je suis sur Linux depuis plus de 20 ans et je n'en suis pas déçu. Mais plutôt un remarquable système, bien documenté, solide, ouvert, cohérent, qui a dû faire avec les obstacles générés par Microsoft avec sa main mise sur les constructeurs voir le « Bios » par exemple...

Non aujourd'hui et encore plus demain « Linux » sera et est un système fiable, alors le langage "C" peut-être fiable. Ça ne remet pas en cause "Rust" ce serait idiot...

[Uther]

Non aujourd'hui et encore plus demain « Linux » sera et est un système fiable, alors le langage "C" peut-être fiable. Ça ne remet pas en cause "Rust" ce serait idiot...

Ce n'est pas parce qu'un funambule est capable de traverser un précipice en marchant sur un câble que l'on peut conclure que ça peut-être une façon fiable de traverser. Même si Linux était parfaitement fiable (ce qui n'est pas le cas) ça ne voudrait pas pour autant dire que le langage dans lequel il a été écrit l'est.

L'histoire a montré que aucun langage n'est parfaitement fiable a l'usage, pas même le Rust ou l'Ada, et que le C l'est clairement moins que la moyenne. Il ne s'agit pas de remettre en cause son intérêt, mais d'être conscient de ses limites. Le C est encore la pour longtemps et Linux n'est pas prêt de le remplacer en tant que langage principal.

[Madmac]

code réentrant avec goto ? comment tu libère l'espace sur la pile pour les variables de ta fonction réentrante si tu en sors avec goto ?

La beauté d'un code réentrant est que les variables ont une consommation fixe de mémoire parce qu'elles occupent toujours le même espace. Normalement le code compilé d'une fonction détruire les variables internes et cet espace doit-être récupéré par le ramasse-miette à chaque utilisation de la fonction. Dans un code réentrant, tu n'a pas à récupérer ces espaces, parce que les variables sont globales et qu'elles existent dans un endroit précis pendant toute l'exécution du programme. En pratique, tu laisse des espaces mémoires dans ton bloc de code pour les variables internes.

En langage machine, la façon de faire des boucles se fait avec une instruction qui fonctionne comme un goto. Et pour faire du code réentrant, il faut que précisement au début d'un bloc de code.Avec un goto, le compilateur peut déduire que c'est que ce que tu désire faire. Alors qu'avec un truc comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while(1)

rien ne garantie qu'il le compilera de cette façon. Alors la seule façon d'être sûre est d'écrire le code en langage machine. Ce qui est emmerdant quand on considère que le langage pourrait exprimer cette volonté du programmeur sans devoir faire du langage machine. C offre cette souplesse.

[Madmac]

Je ne sais pas si j'ai bien compris, mais j'ai l'impression que tu confonds "goto" et "setjmp".
goto ne permet que de faire un saut local à la fonction, donc toutes les variables de la pile seront nettoyées.

Dans un code réentrant, il n'y a pas de nettoyage de variable. Les espaces occupé par ces variable sont contenu dans le bloc d'instruction.(à moins que l'on utilise un pointeur ..)

J
Pour ma part, le seul usage pertinent, c'est de faire une sorte de gestion d'exception :

C'est également une façon intelligente de l'utiliser, car un peut produire des exceptions très compacte avec un longjmp.

[JPLAROCHE]

Ce n'est pas parce qu'un funambule est capable de traverser un précipice en marchant sur un câble que l'on peut conclure que ça peut-être une façon fiable de traverser. Même si Linux était parfaitement fiable (ce qui n'est pas le cas) ça ne voudrait pas pour autant dire que le langage dans lequel il a été écrit l'est.

L'histoire a montré que aucun langage n'est parfaitement fiable a l'usage, pas même le Rust ou l'Ada, et que le C l'est clairement moins que la moyenne. Il ne s'agit pas de remettre en cause son intérêt, mais d'être conscient de ses limites. Le C est encore la pour longtemps et Linux n'est pas prêt de le remplacer en tant que langage principal.

Quand je dis "Fiable" c'est c'est un système qui tien la route. Personnellement je peux développer et sur mes plus 20 ans passés je peux dire que rarement Linux m'a posé des problèmes ci ce n'est moi qui par mes manipulations j'ai fait dans mon apprentissage de "Linux" des erreurs de débutant.

Le langage "C" a tenu ses promesses et bien utilisé ne pose pas de problèmes. Ça ne veut pas dire qu'il est dépourvu d'incohérence s'il est mal utilisé ce que tente de faire "Rust" ( de corriger cette incohérence).

J'ai aimé "ADA" pour sa clarté et solidité. Il y a d'autre langage aujourd'hui qui aussi se penche sur l'élimination d'incohérence qui peuvent mener au scratch et qui ne sont pas tourné vers le Système(son écriture).

Je continue de croire que "C" est le langage assembleur le plus simple et ouvert. ( je n'ai pas dit que c'était de l'assembleur), peut-être parce que je suis de la vieille école ou j'ai appris en comptant les bites des instructions... (MI d'IBM) Interface Machine.

j'aimerais avoir un vrai langage tourné vers le système et uniquement vers le système, et un langage tourné uniquement vers le développement par exemple gestion, on aurait certainement des choses d'une part beaucoup plus simple et qui ne se mélangerait pas les pinceaux. Là on ne trouverait pas des programmes qui font papa maman Alfred et la bonne sœur avec un bordel sans nom...

Bon on en revient à comment « Écrire du Code Propre » un sujet qui été traité dans dévellopez.net et là bien traité quel que soit le langage.

[chrtophe]

Je ne sais pas si j'ai bien compris, mais j'ai l'impression que tu confonds "goto" et "setjmp".

Ah oui, effectivement, j'ai dis une connerie.
Après usage de goto dans certains cas à bon escient pourquoi pas, mais pour moi il vaut mieux le bannir vu qu’on a les structures adéquates pour l'éviter.

[JPLAROCHE]

Ah oui, effectivement, j'ai dis une connerie.
Après usage de goto dans certains cas à bon escient pourquoi pas, mais pour moi il vaut mieux le bannir vu qu’on a les structures adéquates pour l'éviter.

Pourquoi bannir.
Pourquoi pas prévenir et bien enseigner comment et pourquoi l'utiliser. Des débranchements fait correctement permettent de faire des choses propres. Ça ne veut pas dire faire des boucles while ect...

[Madmac]

Après usage de goto dans certains cas à bon escient pourquoi pas, mais pour moi il vaut mieux le bannir vu qu’on a les structures adéquates pour l'éviter.

Le problème est que ce n'est pas le cas avec tous les langages. Dans le cas de boucle imbriqué, si je dois géré une erreur fatale à l'intérieur de ma boucle interne, je dois ajouter un autre test de branchement dans ma boucle externe pour gérer cette erreur. Alors qu'avec un goto je peux sortir rapidement de ma fonction peut importe ou je suis.

Honnêtement je trouve la façon de gérer les exceptions dans la plupart des langages qui ne disposent pas du goto, complexe et pénible.

[chrtophe]

Pourquoi bannir.

Bannir pour mon usage, j'envisagerais de l'utiliser si je monte en compétences C (je suis pas programmeur de métier) et si j'en ai besoin. En attendant, pour mon usage, mieux vaut utiliser les structures de type while switch. Pour reprendre l'expression d'Uther, je vais éviter de faire le funambule.

L'option code safe de Rust serait tout à fait adapté pour quelqu'un comme moi, qui se débrouille en C, mais n'en est pas un professionnel. Ça pourrait protéger mon code de mauvaises pratiques, d'oubli, etc.