Comportamento indefinido, não especificado e definido pela implementação

O que é um comportamento indefinido em C e C ++? E o comportamento não especificado e o comportamento definido pela implementação? Qual a diferença entre eles?

O comportamento indefinido é um daqueles aspectos da linguagem C e C ++ que pode surpreender os programadores vindos de outras linguagens (outras linguagens tentam escondê-lo melhor). Basicamente, é possível escrever programas em C ++ que não se comportam de maneira previsível, mesmo que muitos compiladores em C ++ não relatem erros no programa!

Vejamos um exemplo clássico:

#include <iostream>

int main()
{
    char* p = "hello!\n";   // yes I know, deprecated conversion
    p[0] = 'y';
    p[5] = 'w';
    std::cout << p;
}

A variável paponta para a string literal "hello!\n"e as duas atribuições abaixo tentam modificar essa string literal. O que este programa faz? De acordo com a seção 2.14.5, parágrafo 11 do padrão C ++, ele invoca um comportamento indefinido :

O efeito de tentar modificar um literal de cadeia de caracteres é indefinido.

Eu posso ouvir as pessoas gritando "Mas espere, eu posso compilar isso sem problemas e obter a saída yellow" ou "O que você quer dizer com literais de seqüência indefinidos são armazenados na memória somente leitura, para que a primeira tentativa de atribuição resulte em um dump principal". Esse é exatamente o problema do comportamento indefinido. Basicamente, o padrão permite que qualquer coisa aconteça depois que você invoca um comportamento indefinido (mesmo demônios nasais). Se existe um comportamento "correto" de acordo com o seu modelo mental da linguagem, esse modelo está simplesmente errado; O padrão C ++ tem o único voto, ponto final.

Outros exemplos de comportamento indefinido incluem acessar uma matriz além de seus limites, desreferenciar o ponteiro nulo , acessar objetos após o término de sua vida útil ou escrever expressões supostamente inteligentes como i++ + ++i.

A Seção 1.9 do padrão C ++ também menciona os dois irmãos menos perigosos do comportamento indefinido , comportamento não especificado e comportamento definido pela implementação :

As descrições semânticas nesta Norma definem uma máquina abstrata não-determinística parametrizada.

Certos aspectos e operações da máquina abstrata são descritos nesta Norma como definidos pela implementação (por exemplo sizeof(int)). Estes constituem os parâmetros da máquina abstrata. Cada implementação deve incluir documentação descrevendo suas características e comportamento nesses aspectos.

Certos outros aspectos e operações da máquina abstrata são descritos nesta Norma como não especificados (por exemplo, ordem de avaliação dos argumentos de uma função). Onde possível, esta Norma define um conjunto de comportamentos permitidos. Eles definem os aspectos não determinísticos da máquina abstrata.

Certas outras operações são descritas nesta Norma como indefinidas (por exemplo, o efeito de desreferenciar o ponteiro nulo). [ Nota : esta Norma Internacional não impõe requisitos ao comportamento de programas que contêm comportamento indefinido. - nota final ]

Especificamente, a seção 1.3.24 declara:

O comportamento indefinido permitido varia de ignorar completamente a situação com resultados imprevisíveis , comportar-se durante a tradução ou a execução de um programa de maneira documentada, característica do ambiente (com ou sem a emissão de uma mensagem de diagnóstico), até o término de uma tradução ou execução (com a emissão de uma mensagem de diagnóstico).

O que você pode fazer para evitar um comportamento indefinido? Basicamente, você precisa ler bons livros em C ++ de autores que sabem do que estão falando. Parafusos tutoriais da Internet. Bullschildt do parafuso.

Bem, isso é basicamente um copiar-colar direto do padrão

3.4.1 1 comportamento definido pela implementação comportamento não especificado em que cada implementação documenta como a escolha é feita

2 EXEMPLO Um exemplo de comportamento definido pela implementação é a propagação do bit de ordem superior quando um número inteiro assinado é deslocado para a direita.

3.4.3 1 comportamento comportamental indefinido , mediante o uso de uma construção de programa não transportável ou incorreta ou de dados errados, para os quais esta Norma Internacional não impõe requisitos

2 NOTA O possível comportamento indefinido varia de ignorar a situação completamente com resultados imprevisíveis, se comportar durante a tradução ou a execução do programa de maneira documentada característica do ambiente (com ou sem a emissão de uma mensagem de diagnóstico), até o término de uma tradução ou execução (com a emissão de uma mensagem de diagnóstico).

3 EXEMPLO Um exemplo de comportamento indefinido é o comportamento em excesso de número inteiro.

3.4.4 1 comportamento não especificado uso de um valor não especificado, ou outro comportamento em que esta Norma Internacional forneça duas ou mais possibilidades e não imponha outros requisitos sobre os quais é escolhido em qualquer instância

2 EXEMPLO Um exemplo de comportamento não especificado é a ordem na qual os argumentos para uma função são avaliados.

Talvez uma redação fácil possa ser mais fácil de entender do que a definição rigorosa dos padrões.

comportamento definido pela implementação
A linguagem diz que temos tipos de dados. Os fornecedores do compilador especificam quais tamanhos eles devem usar e fornecem uma documentação do que eles fizeram.

comportamento indefinido
Você está fazendo algo errado. Por exemplo, você tem um valor muito grande em um intque não se encaixa char. Como você coloca esse valor char? na verdade não tem como! Tudo poderia acontecer, mas a coisa mais sensata seria pegar o primeiro byte desse int e inseri-lo char. É errado fazer isso para atribuir o primeiro byte, mas é o que acontece sob o capô.

comportamento não especificado
Qual função desses dois é executada primeiro?

void fun(int n, int m);

int fun1()
{
  cout << "fun1";
  return 1;
}
int fun2()
{
  cout << "fun2";
  return 2;
}
...
fun(fun1(), fun2()); // which one is executed first?

O idioma não especifica a avaliação, da esquerda para a direita ou da direita para a esquerda! Portanto, um comportamento não especificado pode ou não resultar em um comportamento indefinido, mas certamente seu programa não deve produzir um comportamento não especificado.

@eSKay Acho que vale a pena editar sua resposta para esclarecer mais :)

pois fun(fun1(), fun2());o comportamento "implementação não está definido"? O compilador tem que escolher um ou outro curso, afinal?

A diferença entre definido pela implementação e não especificado, é que o compilador deve escolher um comportamento no primeiro caso, mas não no segundo caso. Por exemplo, uma implementação deve ter uma e apenas uma definição de sizeof(int). Portanto, não se pode dizer que sizeof(int)é 4 para uma parte do programa e 8 para outras. Diferentemente do comportamento não especificado, onde o compilador pode dizer OK, vou avaliar esses argumentos da esquerda para a direita e os argumentos da próxima função são avaliados da direita para a esquerda. Isso pode acontecer no mesmo programa, por isso é chamado de não especificado . De fato, o C ++ poderia ter sido facilitado se alguns comportamentos não especificados fossem especificados. Dê uma olhada aqui na resposta do Dr. Stroustrup para isso :

Alega-se que a diferença entre o que pode ser produzido, dando ao compilador essa liberdade e exigindo "avaliação ordinária da esquerda para a direita" pode ser significativa. Não estou convencido, mas com inúmeros compiladores "por aí" aproveitando a liberdade e algumas pessoas defendendo apaixonadamente essa liberdade, uma mudança seria difícil e levaria décadas para penetrar nos cantos distantes dos mundos C e C ++. Estou decepcionado que nem todos os compiladores alertam contra códigos como ++ i + i ++. Da mesma forma, a ordem de avaliação dos argumentos não é especificada.

OMI demais "deixa" coisas indefinidas, não especificadas, definidas pela implementação etc. No entanto, é fácil dizer e até dar exemplos, mas difícil de corrigir. Também deve ser observado que não é tão difícil evitar a maioria dos problemas e produzir código portátil.

Do documento oficial de justificativa C

Os termos comportamento não especificado , comportamento indefinido e comportamento definido pela implementação são usados ​​para categorizar o resultado da gravação de programas cujas propriedades o Padrão não descreve, ou não pode, descrever completamente. O objetivo de adotar essa categorização é permitir que uma certa variedade de implementações permita que a qualidade da implementação seja uma força ativa no mercado, além de permitir certas extensões populares, sem remover o cachê de conformidade com a Norma. O Apêndice F da Norma cataloga os comportamentos que se enquadram em uma dessas três categorias.

O comportamento não especificado fornece ao implementador alguma latitude na tradução de programas. Essa latitude não se estende a falhar na conversão do programa.

O comportamento indefinido dá ao implementador licença para não detectar certos erros de programa difíceis de diagnosticar. Ele também identifica áreas de possível extensão de idioma em conformidade: o implementador pode aumentar o idioma fornecendo uma definição do comportamento oficialmente indefinido.

O comportamento definido pela implementação dá ao implementador a liberdade de escolher a abordagem apropriada, mas exige que essa opção seja explicada ao usuário. Os comportamentos designados como definidos pela implementação geralmente são aqueles em que um usuário pode tomar decisões significativas de codificação com base na definição da implementação. Os implementadores devem ter em mente esse critério ao decidir o quão extensa deve ser uma definição de implementação. Como no comportamento não especificado, simplesmente falhar na conversão da fonte que contém o comportamento definido pela implementação não é uma resposta adequada.

Comportamento indefinido vs. comportamento não especificado tem uma breve descrição dele.

Seu resumo final:

Em resumo, o comportamento não especificado é geralmente algo com que você não deve se preocupar, a menos que seu software precise ser portátil. Por outro lado, o comportamento indefinido é sempre indesejável e nunca deve ocorrer.

Historicamente, o Comportamento Definido pela Implementação e o Comportamento Indefinido representavam situações nas quais os autores da Norma esperavam que as pessoas que escrevessem implementações de qualidade usassem julgamento para decidir quais garantias comportamentais, se houver, seriam úteis para programas no campo de aplicação pretendido em execução no alvos pretendidos. As necessidades do código de processamento de números de ponta são bastante diferentes das do código de sistemas de baixo nível, e o UB e o BID oferecem aos escritores de compiladores flexibilidade para atender a essas diferentes necessidades. Nenhuma categoria determina que as implementações se comportem de uma maneira que seja útil para uma finalidade específica ou mesmo para qualquer finalidade. As implementações de qualidade que afirmam ser adequadas a um propósito específico, no entanto, devem se comportar de maneira adequada a esse objetivose a Norma exige ou não .

A única diferença entre o comportamento definido pela implementação e o comportamento indefinido é que o primeiro exige que as implementações definam e documentem um comportamento consistente, mesmo nos casos em que nada que a implementação possa fazer seria útil . A linha divisória entre eles não é se geralmente seria útil para implementações definir comportamentos (os escritores do compilador devem definir comportamentos úteis quando praticáveis, se o Padrão exige ou não), mas se pode haver implementações em que definir um comportamento seria simultaneamente caro. e inútil . Um julgamento de que tais implementações possam existir não implica, de forma alguma, nenhum julgamento sobre a utilidade de suportar um comportamento definido em outras plataformas.

Infelizmente, desde meados da década de 90, os escritores de compiladores começaram a interpretar a falta de mandatos comportamentais como um julgamento de que as garantias comportamentais não valem o custo, mesmo nos campos de aplicativos onde são vitais e até nos sistemas em que não custam praticamente nada. Em vez de tratar o UB como um convite para exercer um julgamento razoável, os escritores do compilador começaram a tratá-lo como uma desculpa para não fazê-lo.

Por exemplo, dado o seguinte código:

int scaled_velocity(int v, unsigned char pow)
{
  if (v > 250)
    v = 250;
  if (v < -250)
    v = -250;
  return v << pow;
}

a implementação de um complemento de dois não precisaria fazer nenhum esforço para tratar a expressão v << powcomo uma mudança de complemento de dois sem considerar se vera positivo ou negativo.

A filosofia preferida entre alguns dos escritores de compiladores de hoje, no entanto, sugeriria que, porque vsó pode ser negativo se o programa se envolver em Comportamento indefinido, não há razão para que o programa limite o intervalo negativo v. Embora o deslocamento para a esquerda de valores negativos costumava ser suportado em todos os compiladores significativos, e uma grande quantidade de código existente se baseie nesse comportamento, a filosofia moderna interpretaria o fato de o Padrão afirmar que os valores negativos para o deslocamento à esquerda são UB como implicando que os escritores do compilador devem ficar à vontade para ignorá-lo.

Padrão C ++ n3337 § 1.3.10 comportamento definido pela implementação

comportamento, para uma construção de programa bem formada e dados corretos, que depende da implementação e que cada implementação documenta

Às vezes, o C ++ Standard não impõe um comportamento específico em algumas construções, mas diz que um comportamento específico e bem definido deve ser escolhido e descrito por uma implementação específica (versão da biblioteca). Assim, o usuário ainda pode saber exatamente como o programa se comportará, embora o Standard não descreva isso.

Padrão C ++ n3337 § 1.3.24 comportamento indefinido

comportamento para o qual este Padrão Internacional não impõe requisitos [Nota: Um comportamento indefinido pode ser esperado quando este Padrão Internacional omite qualquer definição explícita de comportamento ou quando um programa usa uma construção ou dados errados. O comportamento indefinido permitido varia de ignorar a situação completamente com resultados imprevisíveis, comportar-se durante a tradução ou a execução de um programa de maneira documentada, característica do ambiente (com ou sem a emissão de uma mensagem de diagnóstico), até o término de uma tradução ou execução (com a emissão de uma mensagem de diagnóstico). Muitas construções de programas erradas não geram comportamento indefinido; eles precisam ser diagnosticados. - nota final]

Quando o programa encontra uma construção que não é definida de acordo com o padrão C ++, é permitido fazer o que quiser (talvez envie um email para mim ou talvez envie um email para você ou ignore completamente o código).

N3337 padrão C ++ § 1.3.25 comportamento não especificado

comportamento, para uma construção de programa bem formada e dados corretos, que depende da implementação [Nota: A implementação não é necessária para documentar qual comportamento ocorre. A gama de comportamentos possíveis é geralmente delineada por este Padrão Internacional. - nota final]

O C ++ Standard não impõe um comportamento específico em algumas construções, mas diz que um comportamento específico e bem definido deve ser escolhido ( não é necessário descrever o bot ) por uma implementação específica (versão da biblioteca). Portanto, no caso em que nenhuma descrição foi fornecida, pode ser difícil para o usuário saber exatamente como o programa se comportará.

Implementação definida

Os implementadores desejam, devem ser bem documentados, o padrão oferece opções, mas certamente compila

Não especificado -

O mesmo que definido pela implementação, mas não documentado

Indefinido-

Qualquer coisa pode acontecer, cuide disso.