Rust como Linguagem de Sistemas

Rust conquista o rótulo de "linguagem de sistemas" através de três capacidades específicas que a maioria das linguagens de aplicação ou esconde ou não oferece: acesso direto à fronteira do sistema operacional abaixo das abstrações portáteis da biblioteca padrão, a capacidade de trabalhar com memória bruta e seu layout exato, e uma forma definida de falar a ABI do C para que o código Rust possa chamar, e ser chamado por, código escrito em uma linguagem completamente diferente. Nenhuma dessas é um complemento exótico - é o que "programação de sistemas" concretamente significa, e a resposta de Rust para cada uma é incomumente explícita em comparação com C ou C++.

Esta página conecta essas três capacidades em uma única imagem. As outras páginas da seção - libc e syscalls, memória bruta, bindgen, cbindgen, bindings confiáveis - aprofundam cada peça do que esta página mapeia.

Resumo

• Programação de sistemas em Rust significa trabalhar em três níveis explícitos abaixo das abstrações portáteis de std - a fronteira de syscalls do SO, o layout de memória bruta e a ABI do C - cada um exigindo unsafe e cada um com seu próprio modo de falha.
• Por que Importa: std deliberadamente esconde diferenças de plataforma e layout de memória para segurança e portabilidade; código de sistemas existe precisamente onde esses detalhes ocultos se tornam a coisa que você precisa controlar.
• Conceitos Chave: syscall, libc, layout de memória, repr(C), ABI, FFI, comportamento indefinido.
• Quando Usar: Chamar bibliotecas C, expor Rust para outras linguagens, analisar formatos binários ou precisar de recursos do SO que std não expõe.
• Limitações / Trade-offs: Cada capacidade descrita aqui troca as garantias de segurança padrão de Rust por controle, e o compilador para de verificar o invariante específico que você assumiu.
• Tópicos Relacionados: Rust unsafe, comportamento indefinido, código multiplataforma, design de API confiável.

Fundamentos

Tudo o que std::fs, std::net e std::process fazem, em última análise, se torna uma syscall - uma requisição do seu programa para o kernel do sistema operacional para fazer algo que apenas o kernel tem permissão para fazer, como abrir um descritor de arquivo ou enviar bytes por um socket. std envolve essas syscalls em funções Rust seguras e portáteis que escondem os detalhes específicos da plataforma de como Linux, macOS e Windows expõem essa funcionalidade. Programação de sistemas é o que acontece quando esse wrapper portátil não vai longe o suficiente - quando você precisa de uma syscall, ou um comportamento específico da plataforma, que std intencionalmente não expõe.

O crate libc é a camada diretamente abaixo desse wrapper portátil: bindings brutos para a biblioteca padrão C e as funções POSIX que ela expõe, com os tamanhos e assinaturas de tipo reais do C em vez dos idiomáticos de Rust. Chamar para ele é sempre unsafe, porque o compilador não tem como verificar o contrato de uma função C - apenas as garantias comuns de Rust sobre tipos se foram.

Trabalhar com memória bruta é a segunda capacidade: raciocinar sobre exatamente como os bytes são dispostos, não apenas quais são os campos de um struct. O layout padrão de struct de Rust é deliberadamente não especificado - o compilador é livre para reordenar campos para melhor empacotamento, e duas structs estruturalmente idênticas não têm garantia de ter o mesmo layout entre versões do compilador. Isso é invisível e irrelevante para código Rust comum, e se torna crítico no momento em que outra linguagem, ou um formato de arquivo binário, precisa ler esses bytes com suas próprias expectativas fixas.

A ABI do C é a terceira capacidade: uma Interface Binária de Aplicação (ABI) é o contrato de baixo nível que duas peças de código compilado concordam - como argumentos são passados, como um valor de retorno volta, como os campos de um struct são ordenados na memória. A própria ABI interna de Rust é instável e não documentada, o que é aceitável desde que tudo seja compilado pelo mesmo compilador Rust; a ABI do C, por outro lado, é um padrão de fato estável com o qual quase todas as linguagens e plataformas podem concordar em falar, e é por isso que ela é a linguagem comum pela qual duas linguagens diferentes realmente se comunicam.

Mecânicas e Interações

unsafe é a única palavra-chave que une todas as três capacidades, e ela significa algo preciso: marca um bloco onde você está pessoalmente mantendo um invariante que o compilador não pode mais verificar para você, não um bloco onde as regras de Rust param de se aplicar. Dereferenciar um ponteiro bruto, chamar uma função libc, ou transmutar bytes em um struct são todos unsafe pela mesma razão subjacente - cada um pede que você garanta algo (validade, alinhamento, o contrato documentado de uma função C) que o sistema de tipos não tem como verificar por si só.

repr(C) é o mecanismo que torna o layout de memória de Rust, de outra forma instável, previsível o suficiente para cruzar a fronteira da ABI. Sem ele, a ordem dos campos e o preenchimento de um struct são detalhes de implementação do compilador; com ele, o compilador organiza o struct exatamente como um compilador C faria, com a ordem dos campos preservada, preenchimento inserido da mesma forma, que é a única maneira de outra linguagem ler confiavelmente os bytes de um struct Rust ou vice-versa.

// Sem repr(C), a ordem dos campos e o preenchimento não são especificados - ok dentro do próprio Rust.
// Com repr(C), o layout corresponde ao que um compilador C produziria para os mesmos campos,
// o que torna este struct seguro para compartilhar através da fronteira FFI.
#[repr(C)]
struct Header {
    magic: u32,
    version: u16,
    flags: u16,
}

O tratamento de errno mostra a mesma disciplina de fronteira na outra direção: funções C tipicamente sinalizam falha retornando um valor sentinela (-1, um ponteiro nulo) e definindo um errno local da thread, que Rust lê via std::io::Error::last_os_error() imediatamente após a chamada, porque esse valor local da thread pode ser sobrescrito pela próxima chamada libc que seu código fizer. Esta é a versão da fronteira FFI da mesma lição que o trabalho com memória bruta ensina: o contrato vive na documentação e convenção que o compilador não pode impor, então o código chamador tem que honrá-lo manualmente e imediatamente.

bindgen e cbindgen são duas direções do mesmo problema de cruzamento de ABI, executados ao contrário. bindgen lê um cabeçalho C e gera declarações Rust repr(C) correspondentes, para que o código Rust possa chamar uma biblioteca C existente corretamente. cbindgen lê código Rust e gera um cabeçalho C descrevendo as funções exportadas e os tipos repr(C) da biblioteca Rust, para que o código C possa chamar Rust. Ambos existem porque nenhuma linguagem pode ver diretamente as definições de tipo da outra - o cabeçalho gerado ou os bindings são o artefato que permite que cada lado concorde sobre a ABI compartilhada sem transcrevê-la manualmente e arriscar desvios.

Considerações Avançadas e Aplicações

A posse (ownership) não deixa de ser um conceito de Rust na fronteira FFI - torna-se uma responsabilidade explícita e manual em vez de uma imposta pelo compilador. Box::into_raw entrega a propriedade de uma alocação de heap para C como um ponteiro bruto, e a partir desse ponto o compilador Rust não tem ideia de que a alocação existe; um Box::from_raw correspondente no lado Rust (chamado exatamente uma vez, exatamente quando C terminar com ele) é o que recupera essa propriedade e permite que Drop seja executado. Errar isso em qualquer direção - um double-free ao recuperar a propriedade duas vezes, ou um vazamento por nunca recuperá-la - é agora um problema de contabilidade manual do qual o sistema de tipos optou por sair no momento em que unsafe entregou a propriedade.

Comportamento indefinido (UB) é a aresta mais afiada em toda essa camada, distinto de um erro de tempo de execução comum. Uma syscall falha retorna um erro que o sistema de tipos modela bem; UB é o compilador assumindo que um invariante se mantém (uma leitura de ponteiro desalinhado nunca acontece, um campo repr(packed) nunca é referenciado desalinhado) e gerando código com base nessa suposição, então violá-la não produz uma falha previsível - produz um programa que o compilador nunca foi obrigado a fazer se comportar de forma sensata. Ferramentas como Miri e sanitizers existem especificamente porque testes comuns não conseguem capturar UB; o programa pode parecer funcionar corretamente por anos e ainda depender de um comportamento que o compilador nunca prometeu.

Abstração confiável é a disciplina que torna qualquer uma dessas coisas utilizável por código que nunca vê unsafe de forma alguma: envolvendo ponteiros brutos, chamadas libc ou structs repr(C) atrás de uma API pública segura cujas assinaturas de função sozinhas são suficientes para garantir que os invariantes se mantenham, de modo que os chamadores fora do módulo não possam usá-la indevidamente sem escrever unsafe eles mesmos. Esta é a diferença entre "este código funciona por acaso" e "este código não pode ser feito para violar a segurança da memória de fora deste módulo" - e é o padrão que o restante do ecossistema Rust exige de qualquer crate que exponha FFI.

Conceitos Errôneos Comuns

• "unsafe desativa as verificações de segurança de Rust." - Ele apenas desbloqueia um pequeno conjunto de operações (desreferência de ponteiro bruto, chamada de unsafe fn, acesso a estáticos mutáveis e algumas outras) que o compilador não consegue verificar. Todas as outras regras da linguagem ainda se aplicam dentro de um bloco unsafe.
• "Structs de Rust sempre têm layout compatível com C." - O layout padrão é deliberadamente não especificado e pode diferir entre versões do compilador. Apenas #[repr(C)] (ou repr(transparent)) garante um layout em que outra linguagem pode confiar.
• "Se compila e roda corretamente nos testes, o código FFI é confiável." - Comportamento indefinido pode produzir código que parece funcionar por muito tempo enquanto depende de um invariante que o compilador nunca prometeu de fato, que é exatamente o que ferramentas como Miri existem para capturar que testes comuns não conseguem.
• "Chamar libc diretamente é inerentemente mais 'bruto' ou perigoso que std." - std chama as mesmas syscalls por baixo dos panos; libc apenas remove o wrapper portátil e seguro. As operações não são fundamentalmente mais perigosas, apenas sem guarda.
• "bindgen e cbindgen fazem a mesma coisa." - bindgen gera bindings Rust a partir de um cabeçalho C para chamar para C; cbindgen gera um cabeçalho C a partir de código Rust para ser chamado de C. Eles cruzam a fronteira em direções opostas.

FAQs

Relacionados

• Fundamentos de Sistemas - o guia prático no qual esta página se baseia
• libc & Syscalls - a fronteira do SO em profundidade
• Trabalhando com Memória Bruta - layout, alinhamento e repr(C) em profundidade
• Interoperabilidade com C com bindgen - chamando C de Rust
• Expondo Rust para C (cbindgen) - chamando Rust de C

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.