Por que sair do final de uma função não nula sem retornar um valor não produz um erro do compilador?

Desde que percebi, há muitos anos, que isso não produz um erro por padrão (pelo menos no GCC), sempre me perguntei por que?

Entendo que você pode emitir sinalizadores de compilador para gerar um aviso, mas isso não deveria sempre ser um erro? Por que faz sentido que uma função não nula não retorne um valor para ser válida?

Um exemplo conforme solicitado nos comentários:

#include <stdio.h>
int stringSize()
{
}

int main()
{
    char cstring[5];
    printf( "the last char is: %c\n", cstring[stringSize()-1] ); 
    return 0;
}

... compila.

Os padrões C99 e C ++ não requerem funções para retornar um valor. A declaração de retorno ausente em uma função de retorno de valor será definida (para retornar 0) apenas na mainfunção.

A lógica inclui que verificar se todo caminho de código retorna um valor é bastante difícil e um valor de retorno pode ser definido com assembler incorporado ou outros métodos complicados.

Do rascunho do C ++ 11 :

§ 6.6.3 / 2

A saída do final de uma função [...] resulta em um comportamento indefinido em uma função de retorno de valor.

§ 3.6.1 / 5

Se o controle chegar ao fim mainsem encontrar uma return declaração, o efeito é o de executar

return 0;

Observe que o comportamento descrito em C ++ 6.6.3 / 2 não é o mesmo em C.

O gcc emitirá um aviso se você chamá-lo com a opção -Wreturn-type.

-Wreturn-type Warn sempre que uma função é definida com um tipo de retorno cujo padrão é int. Também avise sobre qualquer declaração de retorno sem valor de retorno em uma função cujo tipo de retorno não seja nulo (cair do final do corpo da função é considerado retornar sem valor) e sobre uma declaração de retorno com uma expressão em uma função cuja o tipo de retorno é nulo.

Este aviso é ativado por -Wall .

Como curiosidade, veja o que esse código faz:

#include <iostream>

int foo() {
   int a = 5;
   int b = a + 1;
}

int main() { std::cout << foo() << std::endl; } // may print 6

Esse código possui um comportamento formalmente indefinido e, na prática, está chamando de convenção e arquitetura dependente. Em um sistema específico, com um compilador específico, o valor de retorno é o resultado da avaliação da última expressão, armazenada no eaxregistro do processador desse sistema.

Por padrão, o gcc não verifica se todos os caminhos de código retornam um valor porque, em geral, isso não pode ser feito. Assume que você sabe o que está fazendo. Considere um exemplo comum usando enumerações:

Color getColor(Suit suit) {
    switch (suit) {
        case HEARTS: case DIAMONDS: return RED;
        case SPADES: case CLUBS:    return BLACK;
    }

    // Error, no return?
}

Você, o programador, sabe que, salvo um erro, esse método sempre retorna uma cor. O gcc confia que você sabe o que está fazendo, para não forçar você a colocar um retorno na parte inferior da função.

javac, por outro lado, tenta verificar se todos os caminhos de código retornam um valor e lançam um erro se não puder provar que todos o fazem. Este erro é obrigatório pela especificação da linguagem Java. Observe que algumas vezes está errado e você deve inserir uma declaração de retorno desnecessária.

char getChoice() {
    int ch = read();

    if (ch == -1 || ch == 'q') {
        System.exit(0);
    }
    else {
        return (char) ch;
    }

    // Cannot reach here, but still an error.
}

É uma diferença filosófica. C e C ++ são linguagens mais permissivas e confiáveis ​​do que Java ou C # e, portanto, alguns erros nas linguagens mais recentes são avisos em C / C ++ e alguns avisos são ignorados ou desativados por padrão.

Você quer dizer, por que sair do final de uma função de retorno de valor (ou seja, sair sem um explícito return) não é um erro?

Primeiramente, em C, se uma função retorna algo significativo ou não é apenas crítica quando o código em execução realmente usa o valor retornado. Talvez o idioma não queira forçá-lo a devolver nada quando você sabe que não vai usá-lo de qualquer maneira na maioria das vezes.

Segundo, aparentemente a especificação da linguagem não queria forçar os autores do compilador a detectar e verificar todos os caminhos de controle possíveis para a presença de um explícito return(embora em muitos casos isso não seja tão difícil de executar). Além disso, alguns caminhos de controle podem levar a funções que não retornam - a característica que geralmente não é conhecida pelo compilador. Esses caminhos podem se tornar uma fonte de falsos positivos irritantes.

Observe também que C e C ++ diferem em suas definições de comportamento nesse caso. No C ++, apenas sair do final de uma função que retorna valor é sempre um comportamento indefinido (independentemente de o resultado da função ser usado pelo código de chamada). Em C, isso causa comportamento indefinido apenas se o código de chamada tentar usar o valor retornado.

É legal no C / C ++ não retornar de uma função que afirma retornar algo. Existem vários casos de uso, como chamada exit(-1), ou uma função que chama ou lança uma exceção.

O compilador não rejeitará C ++ legal, mesmo que leve ao UB, se você estiver pedindo para não fazê-lo. Em particular, você está solicitando que nenhum aviso seja gerado. (O Gcc ainda ativa alguns por padrão, mas quando adicionados, esses parecem estar alinhados com novos recursos, não com novos avisos para recursos antigos)

Alterar o no-arg gcc padrão para emitir alguns avisos pode ser uma mudança de ponta para scripts existentes ou criar sistemas. Os bem projetados também -Walle lidam com avisos ou alternam avisos individuais.

Aprender a usar uma cadeia de ferramentas C ++ é uma barreira para aprender a ser um programador de C ++, mas as cadeias de ferramentas C ++ geralmente são escritas por e para especialistas.

Eu acredito que isso é devido ao código legado (C nunca exigiu declaração de retorno, assim como C ++). Provavelmente existe uma enorme base de código contando com esse "recurso". Mas pelo menos existe -Werror=return-type sinalizador em muitos compiladores (incluindo gcc e clang).

Em alguns casos limitados e raros, pode ser útil sair do final de uma função não nula sem retornar um valor. Como o seguinte código específico da MSVC:

double pi()
{
    __asm fldpi
}

Esta função retorna pi usando assembly x86. Ao contrário da montagem no GCC, não conheço nenhuma maneira returnde fazer isso sem envolver a sobrecarga no resultado.

Tanto quanto eu sei, os compiladores C ++ convencionais devem emitir pelo menos avisos para código aparentemente inválido. Se eu pi()esvaziar o corpo , o GCC / Clang relatará um aviso e a MSVC reportará um erro.

As pessoas mencionaram exceções e exitem algumas respostas. Essas não são razões válidas. Quer lançar uma exceção, ou chamar exit, vai não fazer fluir a execução da função fora da final. E os compiladores sabem disso: escrever uma declaração throw ou chamar exito corpo vazio de pi()interromperá quaisquer avisos ou erros de um compilador.

Sob que circunstâncias não produz um erro? Se ele declara um tipo de retorno e não retorna algo, parece um erro para mim.

A única exceção em que consigo pensar é a main()função, que não precisa de nenhuma returndeclaração (pelo menos em C ++; não tenho nenhum dos padrões C à mão). Se não houver retorno, ele atuará como se return 0;fosse a última declaração.

Parece que você precisa ativar os avisos do compilador:

$ gcc -Wall -Wextra -Werror -x c -
int main(void) { return; }
cc1: warnings being treated as errors
<stdin>: In function ‘main’:
<stdin>:1: warning: ‘return’ with no value, in function returning non-void
<stdin>:1: warning: control reaches end of non-void function
$

É uma violação de restrição em c99, mas não em c89. Contraste:

c89:

3.6.6.4 A returndeclaração

Restrições

Uma returndeclaração com uma expressão não deve aparecer em uma função cujo tipo de retorno seja void.

c99:

6.8.6.4 O return declaração

Restrições

Uma returndeclaração com uma expressão não deve aparecer em uma função cujo tipo de retorno seja void. Uma returndeclaração sem uma expressão deve aparecer apenas em uma função cujo tipo de retorno seja void.

Mesmo no --std=c99modo, o gcc emitirá apenas um aviso (embora sem a necessidade de ativar-W sinalizadores , conforme exigido por padrão ou no c89 / 90).

Edite para adicionar isso em c89, "atingir a }função que encerra uma função é equivalente a executar uma returninstrução sem uma expressão" (3.6.6.4). No entanto, em c99, o comportamento é indefinido (6.9.1).