Como a linguagem Rust impede, na compilação, a ocorrência de acessos inválidos a memória

Elemar Júnior

Uma das características que mais gosto em Rust é que o compilador faz um enorme esforço para detectar prováveis erros de tempo de execução na compilação.

O preço que pagamos por essa “ajuda” do compilador é ter de nos adaptar a alguns conceitos exóticos em programação. Os benefícios são as garantias de que “erros bobos” não vão ocorrer em produção e que não teremos longas horas tentando reproduzir cenários exóticos que causam memory-leaks.

Um código simples que Rust não aceita

No post anterior, apresentamos o seguinte código que o compilador de Rust não aceita:

fn longest(x: &str, y: &str) -> &str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

Esse código, bem simples, recebe duas referências de strings e retorna aquela com mais bytes (assunto para outro post). Então, o que há de errado?

Por que Rust não compila meu código?

Para entender o que está acontecendo, temos que reafirmar duas características chave de Rust:

  • Em Rust, todo objeto no heap é de propriedade de uma, e somente uma, variável. Quando esta variável sai de contexto, Rust automaticamente remove o objeto da memória.
  • Para tornar a vida do programador um pouco menos difícil, Rust possui o conceito de referências semelhante ao que temos em C++. Porém, diferente de C++, há garantias, em tempo de compilação, de que as variáveis de referência não irão “viver” mais tempo que a variável com ownership do valor referenciado.

A função que propomos acima não consegue garantir a segunda característica, como fica explícito no exemplo abaixo:

fn main() {
  let r;
  let s1 = String::from("Elemar");
  {
    let s2 = String::from("Rodrigues Severo Jr");
    r = longest(&s1, &s2);
  }
  println!("r: {}", r);
}

fn longest(x: &str, y: &str) -> &str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

No exemplo, a variável r acabaria fazendo referência para s2, o que obviamente ocasionaria um erro em tempo de execução.

NOTA PESSOAL: Perdi a conta de quantas vezes escrevi código em outras linguagens que cai na armadilha apresentada acima. Por isso mesmo, gosto ainda mais do fato do compilador do Rust me alertar para esse problema em potencial.

Como deixar o compilador feliz

Concordamos que o problema do código em que estamos trabalhando é que não há garantias de que os objetos tenham o mesmo “tempo de vida”. Ou seja, um dos objetos pode “morrer” (ser desalocado) porque sua variável owner pode ter saído de contexto enquanto outra ainda faz referência para seu valor.

Felizmente, a linguagem Rust permite impor uma constraint em funções que podem causar esse tipo de problema.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

No código, o ‘a indica o lifetime das referências. No exemplo, indicamos que os dois parâmetros e o retorno estão em lifetimes compatíveis.

Gosto de como o compromisso de somente trabalhar com valores com lifetime compatível fica explícito no código. Você não?

Como entender mais sobre lifetimes em Rust?

Tanto o código que serve como exemplo, como boa parte da explicação que escrevemos aqui, foram inspirados no capítulo Validating References with Lifetimes (disponível on-line) do excelente livro The Rust Programming Language.

Se você prentende considerar Rust seriamente, recomendo muito fortemente a leitura do livro.

Era isso… por enquanto

Esse foi o segundo post com código aqui na Eximia! Também o segundo sobre Rust. Espero que tenham gostado. Que tal conversarmos sobre o que mostrei aqui nos comentários?

PS:  No post anterior, o Antonio Maniero fez considerações bem bacanas sobre vantagens e desvantagens do modelo de gestão de memória de Rust quando confrontado com ambientes com tracing GC, como .NET. Que tal dar uma lida?

PS 2: Criei um grupo no Facebook para compartilhar ideias e discutir mais sobre Rust. Que tal se inscrever lá?

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
2 Comentários
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Daniel Moreira Yokoyama
Daniel Moreira Yokoyama
3 anos atrás

Mais do que o conceito de Ownership, mas a ideia também de “borrowing” e “move”, e como o compilador restringe o acesso a valores de forma exclusiva para múltiplos readers, ou único writer.
De forma que se existe um único writer, nenhum reader tem acesso, mas uma vez que o writer devolva o acesso, todos os leitores voltam a ter acesso ao valor atualizado.

Antonio Maniero
Antonio Maniero
3 anos atrás

Obrigado pela menção, espero ter sido útil. Desta vez vou dizer que aconteceu o que eu achava, nunca vi um artigo que fosse fácil entender o funcionamento da especificação do tempo de vida. Eu entendi o artigo porque já conheço o assunto, mas quem viu pela primeira vez eu acho que não fica tão claro o que acontece ali. Mas esse é um problema geral, parece que ninguém consegue demonstrar isso facilmente, uma das críticas que faço ao mecanismo, até porque depois vem uma situações mais complexas, e tudo que é difícil de entender não é tão bom. Eu sei que depois que entende fica fácil usar (bom, eu usei pouco, mas ainda não é natural pra mim).

AUTOR

Elemar Júnior
Fundador e CEO da EximiaCo atua como tech trusted advisor ajudando empresas e profissionais a gerar mais resultados através da tecnologia.

NOVOS HORIZONTES PARA O SEU NEGÓCIO

Nosso time está preparado para superar junto com você grandes desafios tecnológicos.

Entre em contato e vamos juntos utilizar a tecnologia do jeito certo para gerar mais resultados.

Insights EximiaCo

Confira os conteúdos de negócios e tecnologia desenvolvidos pelos nossos consultores:

Arquitetura de Dados

Insights de um DBA na análise de um plano de execução

Especialista em performance de Bancos de Dados de larga escala
Arquitetura de Software

Estratégias para modernização do legado

Desenvolvedor .NET/NodeJs e especialista em Kafka com experiência em startups e grandes empresas
Infraestrutura e Nuvem

Migração para a nuvem, mais do que mudança tecnológica, implica em mudança da cultura organizacional

Engenheiro de nuvem, arquiteto de software e especialista em Containers e Devops

Acesse nossos canais

Simplificamos, potencializamos e aceleramos resultados usando a tecnologia do jeito certo

EximiaCo 2022 – Todos os direitos reservados

2
0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

Como a linguagem Rust impede, na compilação, a ocorrência de acessos inválidos a memória

Para se candidatar nesta turma aberta, preencha o formulário a seguir:

Condição especial de pré-venda: R$ 14.000,00 - contratando a mentoria até até 31/01/2023 e R$ 15.000,00 - contratando a mentoria a partir de 01/02/2023, em até 12x com taxas.

Tenho interesse nessa capacitação

Para solicitar mais informações sobre essa capacitação para a sua empresa, preencha o formulário a seguir:

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse nessa solução

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse neste serviço

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

× Precisa de ajuda?