Discussion :

[Bruno]

C-rusted : les avantages de Rust, en C sans les inconvénients,
une analyse des trois chercheurs de l’Université de Parme en Italie

Le langage de programmation Rust est un projet ambitieux de la Fondation Mozilla - un langage qui prétend être la prochaine étape de l'évolution du C et du C++. Au fil des années d'existence de ces langages, certains de leurs défauts fondamentaux n'ont toujours pas été corrigés, comme les erreurs de segmentation, le contrôle manuel de la mémoire, les risques de fuites de mémoire et le comportement imprévisible du compilateur. Rust a été créé pour résoudre ces problèmes tout en améliorant la sécurité et les performances.

Roberto Bagnara, Abraham Bagnara et Federico Serafini trois chercheurs de l’Université de Parme en Italie ont produit un essai dans lequel les chercheurs présentent les avantages de Rust, en C.

Notons que Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités indispensables du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.

Avec Rust, il est possible de développer des pilotes de périphériques, des systèmes embarqués, des systèmes d'exploitation, des jeux, des applications web, et bien d'autres choses encore. Des centaines d'entreprises dans le monde entier utilisent Rust en production pour des solutions multiplateformes et économes en ressources. Des logiciels connus et appréciés, comme Firefox, Dropbox, et Cloudflare, utilisent ce langage. De la startup à la multinationale, du système embarqué au service web à haute disponibilité, Rust serait une excellente solution.

Le langage C est un langage de programmation qui appartient au paradigme de programmation impérative. Inventé au début des 1970 dans les Laboratoires Bell pour aider la programmation du système Unix, C est devenu un des langages les plus utilisés. Il n’est pas consacré qu’à la programmation système. C’est un langage compilé, typé avec des instructions bas-niveau. Voici, ci-dessous, un exemple de programme :

Code :

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
 
#include  
#include  
 
int somme(int); 
 
int 
main(int argc, char **arg){ 
    int i = 10; 
    printf("La somme des %d entiers est %d \n", i, somme(i)); 
return EXIT_SUCCESS ; 
}
 
int 
somme(int i){ 
    int resultat = 0; 
    for (int k = 0; k <= i; k++) 
       resultat += k; 
   return resultat; 
}

Selon les chercheurs, l’effervescence actuelle autour de Rust révèle que l'industrie est prête à accepter que les programmeurs prennent une approche plus disciplinée en adoptant un typage de données fort renforcé par des annotations de programme. C'est le véritable changement de perspective : la technologie pour assister cette nouvelle attitude dans la création de code C avec des garanties d'intégrité sans précédent est disponible, dans son essence, depuis des décennies.

DE C À C-RUSTED

Même si le langage de programmation C est (pour des raisons d'efficacité uniquement) statiquement typé, les types ne définissent que la représentation interne des données et rien de plus : les types en C n'offrent pas aux programmeurs un moyen d'exprimer les propriétés non triviales des données qui sont liées à la logique du programme. Par exemple :

• un fichier ouvert a le même type qu'un fichier fermé ;
• une ressource ou une transaction a le même type indépendamment de son état ;
• une référence exclusive et une référence partagée à une ressource sont indiscernables ;
• un nombre entier avec des valeurs spéciales qui représentent des conditions d'erreur est indiscernable d'un nombre entier ordinaire.

En C-rusted, toutes ces différences peuvent être exprimées de manière incrémentielle, ce qui permet d'améliorer la documentation, la lisibilité et la réutilisation du code. Plus important encore, cela permet à C-rusted Analyzer, qui est basé sur la plateforme de vérification logicielle, de vérifier l'exactitude avec n'importe quelle architecture, et pour chaque compilateur.

Pour illustrer, les chercheurs présentent le programme ci-dessous, que le compilateur GNU C compile sans aucun avertissement, même avec un niveau d'avertissement très élevé. Le programme contient beaucoup d'erreurs, y compris l'incrément numérique sans signification.

Code :

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
#include 
#include 
#include 
#define BUFSIZE (100U) 
extern void process(char *string); 
int main(int argc, const char *argv[]) { 
if (argc != 2)
   return 1; 
int fd = open(argv[1], O_RDONLY); 
char *buf = (char *) malloc(BUFSIZE); 
++fd; 
ssize_t bytes = read(fd, buf, BUFSIZE - 1U); 
buf[bytes] = '\0'; 
process(buf); 
return 0;
}

Un programme C compilant sans avertissement avec gcc -c -std=c18 -Wall -Wextra -Wpedantic

Lorsqu'il est soumis à l'analyseur C-rusted, le même programme déclenche plusieurs diagnostics, résumés dans le tableau ci-dessous où la notation wn sur un point du programme signifie que l'avertissement indiqué est donné à ce point du programme.

Code :

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
#include 
#include 
#include
 #define BUFSIZE (100U) 
extern void process(char *string); 
int main(int argc, const char *argv[]) { 
    if (argc != 2) 
        return 1; 
   int fd = open(argv[1], O_RDONLY); 
   char *buf = (char *) malloc(BUFSIZE); 
  ++fdw1; 
ssize_t bytes = read(fdw2, bufw3 , BUFSIZE - 1U); 
buf[bytes] w4w5 = '\0'; 
process(bufw6);
returnw7w8 0; 
}

w1 : Après avoir reçu la valeur de retour de open(), fd contient un descripteur de fichier ou la valeur erronée -1 : fd ne peut pas être incrémenté ;
w2, w3, w4, w5 : fd n'est pas un descripteur de fichier valide, bytes peut être -1, buf peut être NULL ;
w6 : Est-ce que process() prend la propriété, c'est à dire peut/doit-il désallouer son argument ?
w7 : Le descripteur de fichier contenu dans fd est certainement fui ici ;
w8 : La mémoire pointée par buf est possiblement divulguée ici ;

L'analyseur C-rusted donne plusieurs avertissements sur le même programme C

Une version beaucoup plus saine du programme est illustrée ci-dessous :

Code :

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
#include 
#include 
#include 
// Include C-rusted declarations, e.g., for e_hown. 
#include 
#define BUFSIZE (100U) 
// The actual parameter must be a valid (hence, non-null) pointer to a char array 
// in the heap of which process() will take ownership, which implies the caller 
// must have ownership for otherwise it would be unable to pass it on. 
extern void process(char * e_hown string); 
int main(int argc, const char *argv[]) { 
     if (argc != 2) 
          return 1; 
     int fd; // `fd` value is indeterminate. 
     fd = open(argv[1], O_RDONLY); 
     // `fd` value is either the erroneous value -1 or an open file descriptor. 
     if (fd == -1) 
          return 1; 
     // `fd` value is definitely an open file descriptor. 
     char *buf = (char *) malloc(BUFSIZE); 
     // `buf` value is either null or points to a heap-allocated char array. 
     if (buf == NULL) 
          return 1; 
     // `buf` value definitely points to a heap-allocated char array. 
     ssize_t bytes = read(fd, buf, BUFSIZE - 1U); 
     // `bytes` value is either the erroneous value -1 or the number of bytes 
    // read into `buf`. if (bytes == -1) 
           return 1; 
   // `bytes` value is definitely the number of bytes read into `buf`. 
   buf[bytes] = '\0'; 
  // process() takes ownership of `buf` and will deallocate it: no memory leak. 
 process(buf); 
 // close() properly closes the file descriptor contained into `fd`: 
 // no file descriptor leak. 
 close(fd); 
// `fd` value is an ordinary integer and cannot be used as a file descriptor 
// (it can be overwritten of course). 
// ... 
return 0; 
}

Le C-rusted Analyzer ne donne aucun avertissement sur ce program

Elle montre clairement que, bien que le type (statique) de fd soit int, pendant toute sa durée de vie, la valeur de fd a des propriétés qui changent tout au long du corps de la fonction ; de même pour buf et les bytes. En d'autres termes, le système de types C est capable de suivre les propriétés dynamiques des objets.

Selon les chercheurs, C-rusted est une solution pragmatique et rentable pour élever le jeu de la programmation C à des garanties d'intégrité sans précédent, sans renoncer à ce que l'écosystème C offre aujourd'hui. « C'est-à-dire continuer à utiliser le C, exactement comme avant, en utilisant les mêmes compilateurs et les mêmes outils, le même personnel, mais en ajoutant progressivement au programme les informations requises pour démontrer la correction, en utilisant un système d'annotations qui n'est pas basé sur la logique mathématique et qui peut être enseigné aux programmeurs en une semaine de formation. »

Ce n'est que lorsque l'ajout d'annotations montre la présence d'un problème qu'une modification du code sera nécessaire afin de corriger le bug latent qui est alors visible : dans tous les autres cas, le comportement du code restera exactement le même. Cette technique n'est pas nouvelle : elle s'appelle le typage progressif et consiste à ajouter des informations qui ne sont pas nécessaires à la compréhension du code, mais qui permettent de vérifier son exactitude.

Source : Roberto Bagnara, Abraham Bagnara et Federico Serafini, chercheurs de l’Université de Parme

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Rust 1.65 est disponible, elle apporte les types génériques associés stables, ils permettent d'avoir des génériques (type, lifetime, ou const) sur les types associés

La prise en charge de Rust pour le développement du noyau Linux fait l'objet d'une nouvelle série de discussions, après une proposition de RFC

[Sve@r]

Bonjour

Pour illustrer, les chercheurs présentent le programme ci-dessous, que le compilateur GNU C compile sans aucun avertissement, même avec un niveau d'avertissement très élevé. Le programme contient beaucoup d'erreurs, y compris l'incrément numérique sans signification.

Code :

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
#include 
#include 
#include 
#define BUFSIZE (100U) 
extern void process(char *string); 
int main(int argc, const char *argv[]) { 
if (argc != 2)
   return 1; 
int fd = open(argv[1], O_RDONLY); 
char *buf = (char *) malloc(BUFSIZE); 
++fd; 
ssize_t bytes = read(fd, buf, BUFSIZE - 1U); 
buf[bytes] = '\0'; 
process(buf); 
return 0;
}

"Sans erreur ou avertissement"... Testons donc cela...
Voici le résultat de la compilation telle que mentionnée (gcc -c -std=c18 -Wall -Wextra -Wpedantic) du code cité en référence (compilateur gcc 11.3.0 sur une Ubuntu 22.04 LTS)...

Code :

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
x.c:1:10: error: #include expects "FILENAME" or <FILENAME>
    1 | #include
      |          ^
x.c:2:10: error: #include expects "FILENAME" or <FILENAME>
    2 | #include
      |          ^
x.c:3:10: error: #include expects "FILENAME" or <FILENAME>
    3 | #include
      |          ^
x.c: In function ‘main’:
x.c:9:10: warning: implicit declaration of function ‘open’ [-Wimplicit-function-declaration]
    9 | int fd = open(argv[1], O_RDONLY);
      |          ^~~~
x.c:9:24: error: ‘O_RDONLY’ undeclared (first use in this function)
    9 | int fd = open(argv[1], O_RDONLY);
      |                        ^~~~~~~~
x.c:9:24: note: each undeclared identifier is reported only once for each function it appears in
x.c:10:22: warning: implicit declaration of function ‘malloc’ [-Wimplicit-function-declaration]
   10 | char *buf = (char *) malloc(BUFSIZE);
      |                      ^~~~~~
x.c:1:1: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
  +++ |+#include <stdlib.h>
    1 | #include
x.c:10:22: warning: incompatible implicit declaration of built-in function ‘malloc’ [-Wbuiltin-declaration-mismatch]
   10 | char *buf = (char *) malloc(BUFSIZE);
      |                      ^~~~~~
x.c:10:22: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
x.c:12:1: error: unknown type name ‘ssize_t’
   12 | ssize_t bytes = read(fd, buf, BUFSIZE - 1U);
      | ^~~~~~~
x.c:12:17: warning: implicit declaration of function ‘read’ [-Wimplicit-function-declaration]
   12 | ssize_t bytes = read(fd, buf, BUFSIZE - 1U);
      |                 ^~~~

Donc "sans erreur ou avertissement" faut le dire vite quoi parce que de mon côté j'ai eu l'impression que le compilo m'aurait craché à la figure s'il l'avait pu...

Quel est votre avis sur le sujet ?

Ben déjà donc à partir du moment où on exagère les défauts d'un trucX c'est assez facile de promouvoir le trucY. Mais aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers. (Herbert Mayer).

Mon prof de piano avec qui on discute et où on parlait des artistes en général (ceux qui accompagnent les chanteurs) m'a dit justement hier que ce ne sont pas les chanteurs qui choisissent leurs musiciens mais les autres musiciens. Et tout se fait au bouche à oreille. Si un type commence à fréquenter les milieux en se disant musicien il finira par être appelé. Mais c'est sur la scène qu'il devra prouver sa valeur. S'il joue bien on ne lui dira rien mais il sera redemandé. Et s'il ne joue pas bien, on ne lui dira rien non plus mais il ne sera plus rappelé. Je pense que c'est un peu pareil avec les langages de prog. Peut-être que le Rust est un super langage (je ne le connais que très peu donc je n'ai aucune raison de le critiquer) mais ce n'est pas en disant "ouais regardez le C ceci, le C cela" qu'il percera. C'est en faisant ses propres preuves. On ne s'élève jamais en enfonçant les autres...

[edit]
Pardon pardon, il y a une erreur dans la retranscription du code qu'a fait Bruno (hier quand j'ai testé je n'étais pas allé voir le PDF).
Le code exact de l'article commence par ces 3 lignes

Code c :

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

1
2
3
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>

Le code recopié ici ne montre pas les include complets. Et si on corrige alors effectivement le compilateur digère le tout sans broncher.

Mais cela ne change rien au reste de ce que je pense. Le C a été conçu avec une philosophie assumée du "je laisse faire le programmeur car il sait ce qu'il fait". Donc si le programmeur fait n'importe quoi tout en restant syntaxiquement correct il n'y a aucune raison que le compilateur râle. Ce n'est donc pas la peine de venir ensuite le montrer du doigt en disant "oh regardez le compilateur n'a rien dit" car je le répète, cela était le prédicat initial et assumé de ce langage qui a, rappelons le, été créé en 1968 à l'époque où les ordinateurs n'avaient que 4Ko de RAM et qui donc peut difficilement rivaliser avec un langage du XXI° siècle. Sauf qu'en réalité il n'en a pas besoin, lui il a fait ses preuves.

[Bousk]

Je suppose que le forcing de Rust est sensé attirer les gens à s'y intéresser. Perso ça a fini par me faire tout l'inverse
Rust peut tout faire, et est utilisé par des centaines d'entreprises. Woohoo ce nombre est énorme. Je pense qu'il va falloir forcer encore un peu pour percer ?

[thamn]

La version "beaucoup plus saine" du programme ne libere pas la memoire qu'il alloue? Dans tout le PDF, il n'y a pas un seul exemple qui ne fuite pas de memoire, et le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.

Je sais pas peut-etre c'est une erreur, mais un "analyseur" supposé rendre le code C plus robuste qui rate ça je m'en passe volontier. Et c'est fatiguant d'entendre tout le monde essayer de rendre les autres langages similaire a Rust ou clamer que c'est possible.

[foetus]

La version "beaucoup plus saine" du programme ne libere pas la memoire qu'il alloue? Dans tout le PDF, il n'y a pas un seul exemple qui ne fuite pas de memoire,

le commentaire dit que c'est la fonction process qui devient propriétaire et libère le buffer : "process() takes ownership of `buf` and will deallocate it: no memory leak."

et le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.

je dirais que le pire c'est de faire l'allocation avant l'ouverture. Il y a + de chances que l'ouverture échoue que l'allocation.

Les exemples, pour moi, sont pertinents dans 1 sens : 1 développeur qui connait le C mais ne connait pas/ peu le C "industriel" (les normes, les règles de codage, le C défensif, …), tu le mets derrière cet analyseur C-rusted et son code devient presque opérationnel.
Le code "sain" ici c'est du "C défensif" du style :

Code :

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
#include <stdlib.h>
 
#include <fcntl.h>
#include <sys/types.h>
#include <unistd.h>
 
 
#define BUFSIZE (100U)
extern void process(char* string);
 
 
int main(int argc, const char *argv[])
{
    int ret;
 
    if (argc == 2) {
        int fd = open(argv[1], O_RDONLY);
 
        if (fd != -1) {
            char* buf = malloc(BUFSIZE);
 
            if (buf != NULL) {
                ssize_t bytes = read(fd, buf, BUFSIZE - 1U);
 
                if (bytes != -1) {
                    buf[bytes] = '\0';
                    process(buf); // without free
 
                    ret = EXIT_SUCCESS;
                } else {
                    ret = 1; // error - read
                }
 
                free(buf);
            } else {
                ret = 1; // error - allocation
            }
 
            close(fd);
        } else{
            ret = 1; // error - open
        }
    } else {
        ret = 1; // error - arg
    }
 
 
    return ret;
}

Édit : @Sve@r a trouvé 1 coquille : (que j'ai corrigé)

[smarties]

Je suppose que le forcing de Rust est sensé attirer les gens à s'y intéresser. Perso ça a fini par me faire tout l'inverse

Je n'ai pas l'impression que ça soit la fondation Mozilla qui mettent en avant RUST plus que nécessaire. Je ressens plus une volonté d'un certain nombre d'entreprises et ici d'université de mettre en avant ce langage au détriment des autres.

J'ai adopté RUST mais je ne vais pas forcer les autres à l'utiliser ni dénigrer le C et le C++.
Ma pensée sur le C et le C++ est qu'ils ont fait leurs preuves, on ne va pas réécrire tout le code existant, qu'ils ont des défauts qui peuvent être corrigés en RUST. Je soutiens toutefois la question à se poser d'utiliser RUST quand on initie de nouveaux projets.

[Sve@r]

Le code "sain" ici c'est du "C défensif" du style...

Attention, je pense que tu as écrit une coquille en continuant le travail dans la partie if (bytes == -1). Pour moi faut inverser le test
Ou alors c'est que tu veux faire du "défensif++"...

[mintho carmo]

le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.

A partir du moment ou process prend un pointeur et prend l'ownership, pas d'autre choix que de faire une allocation dynamique.

Par contre, on peut critiquer le choix de design de celui qui a fait process comme ca et oblige a faire de l'allocation dynamique.

le commentaire dit que c'est la fonction process qui devient propriétaire et libère le buffer : "process() takes ownership of `buf` and will deallocate it: no memory leak."

Il y a un return entre le malloc et l'appel de process, donc bien une "fuite".

c'est du "C défensif"

Au final, pas reellement "defensif". Juste "correct".

tu as écrit une coquille en continuant le travail dans la partie if (bytes == -1).

et

Le C a été conçu avec une philosophie assumée du "je laisse faire le programmeur car il sait ce qu'il fait".

40 lignes de code et une erreur critique (ou pas, elle sera vite detectee au moindre test). Alors que foetus est un dev experiemente. Ca illustre assez bien la limite de "le dev sait ce qu'il fait".

[Sve@r]

Par contre, on peut critiquer le choix de design de celui qui a fait process comme ca et oblige a faire de l'allocation dynamique.

Rien n'oblige au malloc. On passe la chaine (alloué ou statique) au process qui pourra la traiter. Je pense que le malloc (avec son free déporté) ont été mis exprès pour mieux illustrer le danger du C mal écrit.

40 lignes de code et une erreur critique (ou pas, elle sera vite detectee au moindre test). Alors que foetus est un dev experiemente. Ca illustre assez bien la limite de "le dev sait ce qu'il fait".

Ah bien vu, je me suis autobaisé

[mintho carmo]

Rien n'oblige au malloc (enfin je crois)

Si la fonction prend l'ownership, c'est qu'elle va appeler elle meme "free" sur le pointeur. Si c'est pas une allocation dynamique, il y a un probleme.

Code :

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

1
2
3
4
5
6
7
8
void process(char *string) {
    ...
    free string; // a priori, la fonction appelle free
    ...
}
 
char s[BUFFER_SIZE]; 
process(&s); // oups

C'est d'ailleurs une des critiques du C (et en partie du C++) : le fait que l'ownership n'est pas explicite et donc que le compilateur ne peut apporter aucune garantie sur l'ownership. C'est un des points que Rust essaie de corriger, en rendant l'ownership explicite et obligatoire.

[Sve@r]

Si la fonction prend l'ownership, c'est qu'elle va appeler elle meme "free" sur le pointeur. Si c'est pas une allocation dynamique, il y a un probleme.

Ah ben évidemment que si "buf" n'est pas alloué il ne faut plus appeler free() !!!
Quand je dis que la chaine peut-être allouée ou statique, je veux dire qu'on peut faire le choix de la mettre en statique mais bien entendu il faut adapter ensuite la fonction process() en conséquence.

En allant même plus loin, la fonction process() n'a absolument pas à présumer de l'origine de la chaine et à tenter une libération. Dans le C que je pratique, le code aurait été celui-ci

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
void process(char *string) {
	... traitement string par exemple fputs(string, stdout) ...
}
 
int main() { 
	char s[/* BUFFER_SIZE + 1 éventuellement mais en faisant gaffe qu'il y ait assez de place */]="Hello World\n";
	process(s);
 
	char *pt="Hello World\n";
	process(pt);
 
	char *m=malloc((BUFFER_SIZE + 1) * sizeof(*m));
	if (m != NULL) {
		m[BUFFER_SIZE]='\0';
		strncpy(m, "Hello World\n", BUFFER_SIZE);
		process(m);
		free(m);
	}
}

Mais bon, comme je l'ai dit, je pense que le code intial a été volontairement rendu abscons pour amplifier les soucis possibles.

[Bousk]

C'est d'ailleurs une des critiques du C (et en partie du C++) : le fait que l'ownership n'est pas explicite et donc que le compilateur ne peut apporter aucune garantie sur l'ownership. C'est un des points que Rust essaie de corriger, en rendant l'ownership explicite et obligatoire.

Oui en C, mais en C++, depuis maintenant 2011 et le C++11 et std::unique_ptr, il n'y a vraiment plus aucune excuse d'avoir du code où l'ownership n'est pas explicite ou connu. Et pour les buffers et autres chaînes de caractères, il y avait déjà std::vector ou std::string.
Alors oui il reste sûrement des vieux codes qui traînent encore ça, où soit le code marche et personne y touche, soit il sera réécrit, et il va falloir justifier de passer ça en Rust au lieu de rester en C++, donc potentiellement recruter des personnes qui connaissent Rust parce que l'équipe en place pas forcément, voire qui devra connaître les 2 pour pouvoir naviguer dans les codes.
Il me semble donc plus simple de rester en C++ dans un cas pareil.

[mintho carmo]

Dans le C que je pratique (...) le code intial a été volontairement rendu abscons pour amplifier les soucis possibles.

Oui, je pense pareil pour le code abscons, la majorité des devs n'auraient pas fait une fonction qui prend l'ownership ici.

il n'y a vraiment plus aucune excuse d'avoir du code où l'ownership n'est pas explicite ou connu (...) il reste sûrement des vieux codes qui traînent encore ça

Tu réponds toi même au problème. (Et je pensais aux smart ptrs dans mon "en partie")

Et qui "trainent" ? Bonne question. Quelle est la proportion de code sans ownership dans les codes pro ? Je sais pas trop. Et on a aussi les codes "modernes" avec pointeurs nus (Qt, interfaces avec des libs C).

Ce qui est sur, c'est qu'un langage qui va obliger a specifier l'ownership sera un avantage par rapport a un langage qui laisse les devs faire n'importe quoi. (Je précise, je suis pas fan de Rust, je ne le défend pas).

[foetus]

Il y a un return entre le malloc et l'appel de process, donc bien une "fuite".

Effectivement … mais le if est dans le commentaire (troisième code, ligne 27) ce qui n'est pas très malin
Sûrement 1 mauvais copier-coller ou alors si on ne peut pas faire confiance aux développeurs, mais faire confiance aux moulinettes n'est pas mieux

Au final, pas reellement "defensif". Juste "correct".

Pour moi le "C défensif" c'est tester tous les retours.

l'ownership n'est pas explicite ou connu

Je n'ai jamais travaillé en embarqué, mais l'ownership en C ce n'est pas 1 peu "inutile"
Dans l'exemple, on fait 1 structure avec le descripteur de fichier et le buffer. Ainsi, on "lie" les 2 variables.

Là, comme je l'ai dit avant, le code C dans les exemples, c'est pour moi du code C d'1 développeur qui connait le C mais pas son aspect "industriel".
Et comme le dit @Sve@r, il y a 1 impression d'amplification des erreurs.
Oui le C "vanilla" est très "dangereux" : rien de nouveau

[mintho carmo]

Effectivement … mais le if est dans le commentaire (troisième code, ligne 27)

Oui, le code copié-collé est incorrect. Mais dans le pdf, le code n'est pas correct non plus pour le free et le close.

Pour moi le "C défensif" c'est tester tous les retours.

J'ai pas la même définition, mais peu importe.

l'ownership en C ce n'est pas 1 peu "inutile"

A mon sens, non. Regarde la discussion qu'on a eu a propos de l'ownership de process. Dans une fonction comme process :

Code :

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

void process(char *string)

Le problème est qu'on ne peut pas savoir (sauf a lire correctement la doc, ce que personne ne fait) si le code suivant est correct ou pas :

Code :

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

1
2
char string[BUFFER_SIZE];
process(&string);

S'il y avait un ownership explicite en C, par exemple en supprimer les pointeurs nus et en ayant des pointeurs "owned_ptr" et "not_owned_ptr", on pourrait écrire explicitement :

Code :

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

1
2
3
4
5
6
7
8
9
10
void owned_process(owned_ptr<char> string);
void not_owned_process(not_owned_ptr<char> string);
 
char static_string[BUFFER_SIZE];
char* dynamic_string = malloc(...);
 
owned_process(&static_string);          // compile error
not_owned_process(&static_string);   // ok
owned_process(dynamic_string);       // ok
not_owned_process(dynamic_string); // ok, mais erreur si free est oublié ensuite

Même en C, il serait intéressant d'avoir un ownership explicite, pour le dev (savoir explicitement ce qui est attendu) et le compilateur (detecter systématiquement les erreurs, sans compter sur le fait que le dev ne fasse pas d'erreur).

[Uther]

Quel est votre avis sur le sujet ?

Que le titre "C-rusted : les avantages de Rust, en C sans les inconvénients" est très trompeur. Ce qui est proposé est très loin d'apporter au C tous les avantages du Rust. Il se contente d'apporter une version limitée du "borrow checker"

Le C a été conçu avec une philosophie assumée du "je laisse faire le programmeur car il sait ce qu'il fait". Donc si le programmeur fait n'importe quoi tout en restant syntaxiquement correct il n'y a aucune raison que le compilateur râle. Ce n'est donc pas la peine de venir ensuite le montrer du doigt en disant "oh regardez le compilateur n'a rien dit" car je le répète, cela était le prédicat initial et assumé de ce langage qui a, rappelons le, été créé en 1968 à l'époque où les ordinateurs n'avaient que 4Ko de RAM et qui donc peut difficilement rivaliser avec un langage du XXI° siècle. Sauf qu'en réalité il n'en a pas besoin, lui il a fait ses preuves.

Le truc justement, c'est que cette philosophie qui se justifiait plutôt bien dans les années 70, ne correspond plus vraiment aux standards que l'on attend de nos outils modernes. De nos jours, il n'y a pas de mal à vouloir des outils qui puissent répondre à des problématiques de sécurité, d'autant plus maintenant qu'avec des langages comme Rust, ça n'implique plus de devoir renoncer à avoir un contrôle de ce qui se passe à plus bas niveau.

La version "beaucoup plus saine" du programme ne libere pas la memoire qu'il alloue? Dans tout le PDF, il n'y a pas un seul exemple qui ne fuite pas de memoire, et le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.

Je sais pas peut-etre c'est une erreur, mais un "analyseur" supposé rendre le code C plus robuste qui rate ça je m'en passe volontier. Et c'est fatiguant d'entendre tout le monde essayer de rendre les autres langages similaire a Rust ou clamer que c'est possible.

C'est sans doute la rédaction très confuse de l'article qui t'induit en erreur. Je te conseille vivement de lire directement l'article source qui est beaucoup plus clair.
Si les premiers exemples te semblent problématiques, c'est normal. Il ne s'agit pas d'exemples de code propre mais, au contraire, de code problématique pour lesquels c-rusted va pouvoir lever des warning qu'un compilateur traditionnel ne lèverait pas.
Dans la dernière version, il n'y a en effet pas de libération de mémoire, mais cette fois c'est normal : C-rusted introduit l'annotation e_hown pour indiquer que la responsabilité de gérer la mémoire est transférée à une autre fonction. Tu peux voir qu'elle est utilisée sur le paramètre de la fonction process et donc que c'est elle qui devra se charger de la libérer la mémoire. Si le code de la fonction main la libérait aussi, ça devrait au contraire lever une alerte car ça serait une erreur de double libération.

Je n'ai pas l'impression que ça soit la fondation Mozilla qui mettent en avant RUST plus que nécessaire. Je ressens plus une volonté d'un certain nombre d'entreprises et ici d'université de mettre en avant ce langage au détriment des autres.

En effet Rust n'a jamais eu de grand sponsors avec de gros intérêt financiers pour les pousser comme ça a pu être le cas de Sun pour Java ou Microsoft pour C#, ... et la fondation Mozilla ne met pas Rust en avant pour la simple et bonne raison quelle ne participe quasiment plus au développement du langage depuis des années. Il y a ajuste des personnes très variées qui y voient un intérêt notamment pour sécuriser les développements bas niveau.

[Freem]

Oui en C, mais en C++, depuis maintenant 2011 et le C++11 et std::unique_ptr, il n'y a vraiment plus aucune excuse d'avoir du code où l'ownership n'est pas explicite ou connu. Et pour les buffers et autres chaînes de caractères, il y avait déjà std::vector ou std::string.
Alors oui il reste sûrement des vieux codes qui traînent encore ça, où soit le code marche et personne y touche, soit il sera réécrit, et il va falloir justifier de passer ça en Rust au lieu de rester en C++, donc potentiellement recruter des personnes qui connaissent Rust parce que l'équipe en place pas forcément, voire qui devra connaître les 2 pour pouvoir naviguer dans les codes.
Il me semble donc plus simple de rester en C++ dans un cas pareil.

Avant C++11 il y avait std::auto_ptr aussi, malgré ses défauts (qui étaient moins nombreux que la gestion manuelle, hein).
A mon avis il est raisonnablement simple d'écrire du C++ sans bugs mémoire, si on interdit les cast C-style, les malloc, realloc, calloc et autre free, en faveur de leurs versions C++: new, delete, static_cast & compagnie.
Pour du C++ "de base" le seul moment ou les pointeurs nus sont encore utiles depuis C++0x, c'est quand on doit passer un pointeur sans ownership, récupéré par exemple à partir de std::unique_ptr<T>::get().

La ou le Rust a peut-être (je me base sur les on-dit, je ne connais pas rust) c'est sur la gestion du parallélisme. A ma connaissance (limitée, j'essaie d'éviter d'avoir besoin de parallélisme, surtout le multi-threadé), les outils disponibles en C++ sont franchement limités.

[destroyedlolo]

Est-ce que c'est vraiment la faute du langage si le programmeur est nul ???
Je passe sur les includes manquantes mais ... par exemple, tout un chacun devrait savoir qu'on teste le résultat d'une allocation. ou d'une ouverture de fichier.

C'est simplement le B.A.-BA !

[foetus]

Est-ce que c'est vraiment la faute du langage si le programmeur est nul ???

Je pense que le nœud du problème c'est que pour faire de l'embarqué, il n'y a que le langage C (et sans parler de la taille de l'existant, depuis les années 70)

Je me rappelle de la sortie de C++11, avec lequel on nous montrait des exemples C++ moderne embarqué meilleurs que le C : exécutable, code source, …
Mais les versions sortent C++14, C++17, … mais il me semble que le C++ embarqué on n'en parle plus beaucoup

Mais le langage C est assez difficile et très long à coder/ déboguer/ … surtout que, je pense que les exigences embarquées doivent être de + en + élevées plus le temps passe.
Et donc, je pense qu'on essaye d'améliorer le C pour que des outils fassent toutes les vérifications "usuelles" sans erreur … et indirectement d'avoir des développeurs avec des profils moins experts/ rares/ … qui excellerait également la vitesse des développements.

Et dans 1 autre fil de discussion je parlais aussi de l'émergence en "conception électronique" de la Chine face à l'hégémonie américaine : création de processeur, création de systèmes d'exploitation, …
Mais pour l'instant, il faut des équipes ultra formées et ultra expérimentées pour cela.

[destroyedlolo]

Je pense que le nœud du problème c'est que pour faire de l'embarqué, il n'y a que le langage C (et sans parler de la taille de l'existant, depuis les années 70)

Ben pas vraiment : j'en fais pour le fun depuis la fin des années 80, et il y avait déjà a l'époque aussi du BASIC (p.e. le fameux 8051), et de nos jours, il y a aussi Lua et malheureusement le uPython. Malheureusement car je trouve qu'il éloigne beaucoup trop du hard et donc on arrive à se retrouver avec des usines a gaz non optimisés.

Je me rappelle de la sortie de C++11, avec lequel on nous montrait des exemples C++ moderne embarqué meilleurs que le C : exécutable, code source, …
Mais les versions sortent C++14, C++17, … mais il me semble que le C++ embarqué on n'en parle plus beaucoup

Ben avec l'Arduino, au contraire, ca se démocratise. Le problème est que ca méthode de développement est très éloigné du C/C++ classique (avec son IDE) et qu'on a, à nouveau, beaucoup de code vraiment pas terrible. Mais les évolutions de GCC profitent aussi à cet écosysteme. Il en va aussi de même pour d'autres solutions. Mais en effet, ce n'est pas trop présent dans les discussions.

Mais le langage C est assez difficile et très long à coder/ déboguer/ … surtout que, je pense que les exigences embarquées doivent être de + en + élevées plus le temps passe.

Bien au contraire, les ST32, les AVR, les ESP ont des ressources sans commune mesure avec ce qui se faisait par exemple il y a seulement une décennie. D'où par exemple la prolifération de code uPython non optimisé voir mal conçus.
Il en va de même dans l'industrie (mon nouveau taf) : on doit géré des évènements de plus en plus rapides, mais même sur les automates, on n'a plus les restrictions de ressources qu'on avait dans le passé.

Et donc, je pense qu'on essaye d'améliorer le C pour que des outils fassent toutes les vérifications "usuelles" sans erreur … et indirectement d'avoir des développeurs avec des profils moins experts/ rares/ … qui excellerait également la vitesse des développements.

Justement, c'est ce qui me gêne. Sur de l'embarqué, qui aurait envi d'avoir des trucs aussi instables que sur PC ? Par exemple, je bosse actuellement sur la modernisation d'un réseau de distribution. Non seulement, l'espérance de vie du bigou est en décennies, mais c'est un système critique, chaque indispo non prévu à des impacts importants, voir critique dans certains cas.