Fil-C torna a memória segura para setjmp/longjmp e ucontext

Fil-C, o dialeto C com segurança de memória, agora suporta setjmp/longjmp e as APIs ucontext (setcontext, getcontext, makecontext, swapcontext) sem corrupção de pilha ou violações de capacidade. O recurso chegou na versão 0.680 e está disponível ao compilar a partir do código-fonte.

O Problema com as APIs de Contexto

Essas APIs são notoriamente inseguras porque o uso indevido pode restaurar uma pilha inválida. Bugs comuns incluem:

• Chamar setjmp ou getcontext em uma função e depois retornar — o contexto salvo aponta para um quadro de pilha que não existe mais.
• Sair da thread e depois tentar restaurar a execução em uma pilha liberada.
• Criar um contexto com makecontext em uma pilha, liberar essa pilha e depois usar swapcontext ou setcontext para ela.
• Passar o contexto atualmente em execução como segundo argumento para swapcontext (trocar para si mesmo).

Em C padrão ("Yolo-C"), esses bugs causam corrupção silenciosa de pilha, travamentos difíceis de depurar e potenciais explorações de segurança. No Fil-C, todos esses casos geram um pânico no ponto do uso indevido.

Como o Fil-C Implementa Segurança de Memória

A abordagem do Fil-C difere para setjmp/longjmp versus ucontext. Para setjmp/longjmp, o principal desafio é que setjmp retorna duas vezes — uma quando chamado, e outra após longjmp. O ato de salvar o contexto significa que o compilador precisa lidar corretamente com variáveis anotadas como voláteis, mas o Fil-C garante que restaurar um contexto nunca acesse memória liberada ou inválida.

Para ucontext, o Fil-C gerencia pilhas de forma que a operação seja legal ou cause pânico, porque quadros de pilha soltos são simplesmente impossíveis.

Exemplo: setjmp/longjmp no Fil-C

O programa a seguir demonstra o comportamento:

#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("Should not get here.\n");
    return 1;
}

Isso imprime x = 666 e sai. Sem volatile, o compilador pode otimizar e imprimir 42. O Fil-C não altera as semânticas de otimização, mas previne corrupção de memória independentemente.

Para Quem?

Desenvolvedores que usam corrotinas baseadas em ucontext (por exemplo, Boost fibers) ou setjmp/longjmp para tratamento de exceções em programas C que desejam segurança de memória.