• # ch'tite dépêche ?

    Posté par  . É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  . É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  (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  . Évalué à 8 (+5/-0).

          C'est dans le Manifesto Manifesto :

          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.

          Ils pensent optimiser dans les futures versions

    • [^] # Re: ch'tite dépêche ?

      Posté par  (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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . Évalué à 5 (+2/-0).

        Quel différence avec Valgrind ?

        "La première sécurité est la liberté"

  • # integer overflow

    Posté par  . Évalué à 8 (+6/-0).

    This branch is 1377 commits ahead of, 68168 commits behind llvm/llvm-project:main.

    Ça donne le vertige.

  • # Tant de questions

    Posté par  (site web personnel) . Évalué à 4 (+3/-0).

    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 !

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.