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 !
# Tant de questions
Posté par corentin38 (site web personnel) . En réponse au lien Fil-C : un C sûr de sa mémoire. Évalué à 4.
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 !