Fil-C rend la mémoire de setjmp/longjmp et ucontext sécurisée

Fil-C, le dialecte C à sécurité mémoire, prend désormais en charge setjmp/longjmp et les API ucontext (setcontext, getcontext, makecontext, swapcontext) sans corruption de pile ni violations de capacité. Cette fonctionnalité est disponible depuis la version 0.680 et lors de la compilation depuis les sources.

Le problème des API de contexte

Ces API sont notoirement dangereuses car une mauvaise utilisation peut restaurer une pile pendante. Les bogues courants incluent :

• Appeler setjmp ou getcontext dans une fonction, puis retourner — le contexte sauvegardé pointe vers une frame de pile qui n'existe plus.
• Quitter le thread, puis essayer de restaurer l'exécution sur une pile libérée.
• Créer un contexte avec makecontext sur une pile, libérer cette pile, puis y accéder avec swapcontext ou setcontext.
• Passer le contexte en cours d'exécution comme second argument à swapcontext (basculer vers lui-même).

En C standard ("Yolo-C"), ces bogues provoquent une corruption silencieuse de la pile, des plantages difficiles à déboguer et des failles de sécurité potentielles. Dans Fil-C, tous ces cas produisent un panic au point de l'erreur.

Comment Fil-C assure la sécurité mémoire

L'approche de Fil-C diffère pour setjmp/longjmp par rapport à ucontext. Pour setjmp/longjmp, le défi principal est que setjmp retourne deux fois — une fois à l'appel, une autre après longjmp. La sauvegarde du contexte impose au compilateur de gérer correctement les variables marquées volatile, mais Fil-C garantit que la restauration d'un contexte n'accède jamais à de la mémoire libérée ou invalide.

Pour ucontext, Fil-C gère les piles de manière à rendre l'opération soit légale, soit à provoquer un panic, car les frames de pile pendantes sont simplement impossibles.

Exemple : setjmp/longjmp dans Fil-C

Le programme suivant illustre le comportement :

#include <setjmp.h>
#include <stdio.h>

int main(int argc, char** argv) {
    volatile int x = 42;
    jmp_buf jb;
    if (setjmp(jb)) {
        printf("x = %d\n", x);
        return 0;
    }
    x = 666;
    longjmp(jb, 1);
    printf("On ne devrait pas arriver ici.\n");
    return 1;
}

Cela affiche x = 666 et se termine. Sans volatile, le compilateur pourrait optimiser et afficher 42 à la place. Fil-C ne modifie pas les optimisations mais empêche la corruption mémoire quoi qu'il arrive.

À qui s'adresse cette fonctionnalité ?

Développeurs utilisant des coroutines basées sur ucontext (par exemple, Boost fibers) ou setjmp/longjmp pour la gestion d'exceptions dans des programmes C souhaitant la sécurité mémoire.