En une ligne : Compilations avec des vérifications à l'exécution. Pour ça des informations sont rajoutées aux pointeurs, et un garbage collector. Ça compile à code source égal y compris sur de gros projets genre MariaDb. Le tout au prix évidemment de perte de performance (4 fois plus lent à l'exec dans le pire des cas).
Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. I'm actively working on performance optimizations for Fil-C, so that 4x number will go down.
C’est clair qu’il a le potentiel d’un game changer… ou presque.
Du "safe" "rust" sans avoir à l’apprendre… Bon avec une pertes de performances par rapport au C original et même par rapport à Rust mais une perte minimale généralement acceptable.
Bien mieux que le "safe C++" moderne qui s’y perd de plus en plus sans assurer le niveau de sécurité de Rust.
Bon Rust ajoutera toujours le côté explicitement safe. J’étends par là qu’il ne fait pas que empêcher les memory leek "segfault". En plus il permet au programmeur de traiter chaque cas de potentiel segfault alors que fil-C fait juste un plantage "propre": exit sans segfault.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Ca ne me parait pas une bonne idée : tu devrais avoir deux versions de ton binaire avec potentiellement des différences de comportement en mode debug et en mode "classique". Tu auras deux runtimes différents, donc potentiellement deux comportements différents. Quand tu fais du multithread, ça peut suffire à ne pas pouvoir reproduire des bugs que tu aurais dans un environnement et pas dans un autre. Et si tu voulais utiliser fil-c pour la phase de test, effectivement ça pourrait te permettre de détecter certaines choses en amont, mais le problème c'est que tes tests ne couvrent pas forcément tous les cas que tu vas rencontrer en prod. Ca peut donc aider, mais ce n'est pas non plus la panacée. Ta prod qui tourne en C classique pourra toujours planter salement.
En lisant en diagonale le readme, on se fait des remarques :
Le quatrième mot du readme est « fanatique ». wow.
Il existe une branche de musl qui s'appelle yolomusl
En gros, le compilateur rajoute un programme qui maintient une liste de chaque pointeur avec la capacité associée, un peu à la façon python, donc. Mais cela pose plein de questions !
Est-ce que ça marche tout le temps ? Eg. si je récupère un pointeur avec un appel de fonction à une lib qui n'a pas été compilée avec fil-c, ou si je fais des casts dégueulasses (void*), ou si j'ai des adresses mémoire très bas niveau qui correspondent à des buffers hardware …
Les erreurs de mémoire donnent ensuite lieu à des « fil-c panics » mais que faire ensuite ? Peut-on les catcher pour les gérer comme on veut ? Est-ce que le programme se termine ? Doit-on s'attendre à ce que chaque accès mémoire nécessite de gérer une potentielle erreur ?
Et bien sûr, quid des undefined behavior ? Si je fais des trucs --i++ avec mes index de tableau et que, par malheur, ça compile, que fera fil-c ?
Les réponses à ces questions sont sans doute dans la doc, hein, mais ain't no time, bro !
# ch'tite dépêche ?
Posté par orfenor . Évalué à 5 (+4/-1).
Tu veux pas écrire une petite dépêche d'intro sur ça ? C'est super intéressant comme projet.
[^] # Re: ch'tite dépêche ?
Posté par thoasm . Évalué à 8 (+5/-0).
En une ligne : Compilations avec des vérifications à l'exécution. Pour ça des informations sont rajoutées aux pointeurs, et un garbage collector. Ça compile à code source égal y compris sur de gros projets genre MariaDb. Le tout au prix évidemment de perte de performance (4 fois plus lent à l'exec dans le pire des cas).
[^] # Re: ch'tite dépêche ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+2/-2).
4 fois? C’est quand même beaucoup. Je pesais que ce serait 50% max ce qui est pour moi acceptable généralement.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: ch'tite dépêche ?
Posté par thoasm . Évalué à 8 (+5/-0).
C'est dans le Manifesto Manifesto :
Ils pensent optimiser dans les futures versions
[^] # Re: ch'tite dépêche ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4 (+4/-1). Dernière modification le 11 mai 2025 à 23:35.
C’est clair qu’il a le potentiel d’un game changer… ou presque.
Du "safe" "rust" sans avoir à l’apprendre… Bon avec une pertes de performances par rapport au C original et même par rapport à Rust mais une perte minimale généralement acceptable.
Bien mieux que le "safe C++" moderne qui s’y perd de plus en plus sans assurer le niveau de sécurité de Rust.
Bon Rust ajoutera toujours le côté explicitement safe. J’étends par là qu’il ne fait pas que empêcher les memory leek "segfault". En plus il permet au programmeur de traiter chaque cas de potentiel segfault alors que fil-C fait juste un plantage "propre": exit sans segfault.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: ch'tite dépêche ?
Posté par orfenor . Évalué à 7 (+5/-0).
Après ces explications, tu n'as plus qu'à te coller à une dépêche!
[^] # Re: ch'tite dépêche ?
Posté par Dring . Évalué à 10 (+11/-1).
Je peux aider en proposant un titre pas du tout putaclic. Genre « Un Rust-Killer écrit en C. Vous serez surpris par les performances. ».
Ou alors…
« Il recompile MariaDB en mode safe-memory en 2 étapes. Vous ne devinerez jamais la seconde ».
[^] # Re: ch'tite dépêche ?
Posté par lrda . Évalué à 2 (+2/-0).
Une grosse différence c'est surtout que ça va se détecter qu'au runtime, là où Rust (et même une partie de C++) va détecter ça à la compilation.
C'est toujours mieux que des vulnérabilités mémoire, mais il y aura un plantage du programme quand même
Ça veut dire qu'avec le Fil-C, le problème n'est pas vu avant qu'il soit testé.
[^] # Re: ch'tite dépêche ?
Posté par inkey . Évalué à 1 (+0/-0).
Du coup l'idée c'est de compilé en fil-c pour debug et de compiler de façon standard en release ?
[^] # Re: ch'tite dépêche ?
Posté par totof2000 . Évalué à 4 (+2/-0).
Ca ne me parait pas une bonne idée : tu devrais avoir deux versions de ton binaire avec potentiellement des différences de comportement en mode debug et en mode "classique". Tu auras deux runtimes différents, donc potentiellement deux comportements différents. Quand tu fais du multithread, ça peut suffire à ne pas pouvoir reproduire des bugs que tu aurais dans un environnement et pas dans un autre. Et si tu voulais utiliser fil-c pour la phase de test, effectivement ça pourrait te permettre de détecter certaines choses en amont, mais le problème c'est que tes tests ne couvrent pas forcément tous les cas que tu vas rencontrer en prod. Ca peut donc aider, mais ce n'est pas non plus la panacée. Ta prod qui tourne en C classique pourra toujours planter salement.
[^] # Re: ch'tite dépêche ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5 (+2/-0).
Quel différence avec Valgrind ?
"La première sécurité est la liberté"
[^] # Re: ch'tite dépêche ?
Posté par Julien Jorge (site web personnel) . Évalué à 2 (+0/-0).
Valgrind est très très lent et ne fait pas de multithread. Je pense que là on est plus près d'AddressSanitizer.
# integer overflow
Posté par steph1978 . Évalué à 8 (+6/-0).
Ça donne le vertige.
# Tant de questions
Posté par corentin38 (site web personnel) . Évalué à 4 (+3/-0).
En lisant en diagonale le readme, on se fait des remarques :
En gros, le compilateur rajoute un programme qui maintient une liste de chaque pointeur avec la capacité associée, un peu à la façon python, donc. Mais cela pose plein de questions !
Les réponses à ces questions sont sans doute dans la doc, hein, mais ain't no time, bro !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.