¿Por qué el flujo del final de una función no nula sin devolver un valor no produce un error del compilador?

Desde que me di cuenta hace muchos años, que esto no produce un error por defecto (al menos en GCC), siempre me he preguntado por qué.

Entiendo que puede emitir indicadores de compilación para generar una advertencia, pero ¿no debería ser siempre un error? ¿Por qué tiene sentido que una función no nula no devuelva un valor para ser válido?

Un ejemplo según lo solicitado en los comentarios:

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

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

... compila.

Los estándares C99 y C ++ no requieren funciones para devolver un valor. La declaración de retorno faltante en una función de retorno de valor se definirá (para devolver 0) solo en la mainfunción.

La lógica incluye que verificar si cada ruta de código devuelve un valor es bastante difícil, y un valor de retorno podría establecerse con un ensamblador incorporado u otros métodos complicados.

Del borrador de C ++ 11 :

§ 6.6.3 / 2

Salir del final de una función [...] da como resultado un comportamiento indefinido en una función de retorno de valor.

§ 3.6.1 / 5

Si el control llega al final de mainsin encontrar una return declaración, el efecto es el de ejecutar

return 0;

Tenga en cuenta que el comportamiento descrito en C ++ 6.6.3 / 2 no es el mismo en C.

gcc le dará una advertencia si lo llama con la opción -Wreturn-type.

-Wreturn-type Avisa siempre que una función se define con un tipo de retorno que por defecto es int. También advierta sobre cualquier declaración de retorno sin valor de retorno en una función cuyo tipo de retorno no es nulo (se considera que la devolución del extremo del cuerpo de la función devuelve sin un valor), y sobre una declaración de retorno con una expresión en una función cuyo return-type es nulo.

Esta advertencia está habilitada por -Wall .

Solo como curiosidad, mira lo que hace este código:

#include <iostream>

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

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

Este código tiene un comportamiento formalmente indefinido y, en la práctica, llama a convenciones y depende de la arquitectura . En un sistema particular, con un compilador particular, el valor de retorno es el resultado de la última evaluación de expresión, almacenada en el eaxregistro del procesador de ese sistema.

gcc no verifica por defecto que todas las rutas de código devuelvan un valor porque, en general, esto no se puede hacer. Asume que sabes lo que estás haciendo. Considere un ejemplo común usando enumeraciones:

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

    // Error, no return?
}

Usted, el programador, sabe que, salvo un error, este método siempre devuelve un color. gcc confía en que sabes lo que estás haciendo, por lo que no te obliga a poner un retorno en la parte inferior de la función.

javac, por otro lado, intenta verificar que todas las rutas de código devuelvan un valor y arroja un error si no puede probar que todas lo hacen. Este error es obligatorio por la especificación del lenguaje Java. Tenga en cuenta que a veces está mal y debe ingresar una declaración de devolución innecesaria.

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

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

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

Es una diferencia filosófica. C y C ++ son lenguajes más permisivos y confiables que Java o C #, por lo que algunos errores en los lenguajes más nuevos son advertencias en C / C ++ y algunas advertencias se ignoran o desactivan de manera predeterminada.

Es decir, ¿por qué fluir del final de una función de retorno de valor (es decir, salir sin un explícito return) no es un error?

En primer lugar, en C si una función devuelve algo significativo o no solo es crítico cuando el código de ejecución realmente usa el valor devuelto. Tal vez el lenguaje no quería forzarlo a devolver nada cuando sabe que no lo va a usar de todos modos la mayor parte del tiempo.

En segundo lugar, al parecer, la especificación del lenguaje no quería obligar a los autores del compilador a detectar y verificar todas las rutas de control posibles para la presencia de un código explícito return(aunque en muchos casos esto no es tan difícil de hacer). Además, algunas rutas de control pueden conducir a funciones que no regresan , el rasgo que el compilador generalmente no conoce. Tales caminos pueden convertirse en una fuente de falsos positivos molestos.

Tenga en cuenta también que C y C ++ difieren en sus definiciones del comportamiento en este caso. En C ++, simplemente fluir al final de una función de retorno de valor siempre es un comportamiento indefinido (independientemente de si el código de llamada utiliza el resultado de la función). En C esto provoca un comportamiento indefinido solo si el código de llamada intenta utilizar el valor devuelto.

Es legal bajo C / C ++ no regresar de una función que dice devolver algo. Hay varios casos de uso, como llamar exit(-1)o una función que lo llama o lanza una excepción.

El compilador no va a rechazar C ++ legal incluso si conduce a UB si le está pidiendo que no lo haga. En particular, solicita que no se generen advertencias . (Gcc todavía activa algunos de forma predeterminada, pero cuando se agregan, estos parecen alinearse con las nuevas funciones, no con nuevas advertencias para las funciones antiguas)

Cambiar el gcc predeterminado sin argumentos para emitir algunas advertencias podría ser un cambio importante para los scripts existentes o los sistemas de fabricación. Bien diseñados, ya sea -Wallcon advertencias o alternar advertencias individuales.

Aprender a usar una cadena de herramientas C ++ es una barrera para aprender a ser un programador C ++, pero las cadenas de herramientas C ++ generalmente están escritas por y para expertos.

Creo que esto se debe al código heredado (C nunca requirió la declaración de retorno, al igual que C ++). Probablemente hay una enorme base de código que se basa en esa "característica". Pero al menos hay una -Werror=return-type bandera en muchos compiladores (incluidos gcc y clang).

En algunos casos limitados y raros, fluir del final de una función no nula sin devolver un valor podría ser útil. Como el siguiente código específico de MSVC:

double pi()
{
    __asm fldpi
}

Esta función devuelve pi usando el ensamblaje x86. A diferencia del ensamblaje en GCC, no conozco ninguna forma returnde hacerlo para esto sin involucrar gastos generales en el resultado.

Hasta donde yo sé, los compiladores de C ++ convencionales deberían emitir al menos advertencias para código aparentemente inválido. Si hago que el cuerpo esté pi()vacío, GCC / Clang informará una advertencia y MSVC informará un error.

La gente mencionó excepciones y exiten algunas respuestas. Esas no son razones válidas. O bien lanzar una excepción, o llamar exit, será no hacer que la ejecución de la función fluya fuera de la final. Y los compiladores lo saben: escribir una declaración de lanzamiento o llamar exital cuerpo vacío de pi()detendrá cualquier advertencia o error de un compilador.

¿En qué circunstancias no produce un error? Si declara un tipo de retorno y no devuelve algo, me parece un error.

La única excepción que se me ocurre es la main()función, que no necesita una returndeclaración (al menos en C ++; no tengo ninguno de los estándares de C a la mano). Si no hay devolución, actuará como si fuera return 0;la última declaración.

Parece que necesitas subir las advertencias de tu 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
$

Es una violación de restricción en c99, pero no en c89. Contraste:

c89:

3.6.6.4 La returndeclaración

Restricciones

Una returndeclaración con una expresión no aparecerá en una función cuyo tipo de retorno sea void.

c99:

6.8.6.4 La returndeclaración

Restricciones

Una returndeclaración con una expresión no aparecerá en una función cuyo tipo de retorno sea void. Una returndeclaración sin una expresión solo aparecerá en una función cuyo tipo de retorno sea void.

Incluso en --std=c99modo, gcc solo lanzará una advertencia (aunque sin necesidad de habilitar -Wbanderas adicionales , como se requiere por defecto o en c89 / 90).

Edite para agregar eso en c89, "alcanzar el }que termina una función es equivalente a ejecutar una returndeclaración sin una expresión" (3.6.6.4). Sin embargo, en c99 el comportamiento es indefinido (6.9.1).