¿Por qué "no todas las rutas de control devuelven un valor" es advertencia y no es un error?

Question

Estaba tratando de responder la pregunta this. Según lo sugerido por la respuesta aceptada, el problema con ese código es que no todas las rutas de control devuelven un valor. Probé este código en el compilador VC9 y me dio una advertencia sobre lo mismo. Mi pregunta es: ¿por qué es solo una advertencia y no un error? Además, en caso de que se ejecute la ruta que no devuelve un valor, ¿qué devolverá la función (tiene que devolver algo)? ¿Es solo lo que hay encima de la pila o es el temido comportamiento indefinido otra vez?

Answer 1

No devolver un valor de una función que tiene un tipo de devolución no void da como resultado un comportamiento indefinido, pero no es un error semántico.

La razón de esto, hasta donde puedo determinar, es en gran parte histórica.

C originalmente no tenía void e implícita int significaba que la mayoría de las funciones devuelven un int menos que se declare explícitamente a volver otra cosa, aunque no había ninguna intención de utilizar el valor de retorno.

Esto significa que muchas funciones devolvieron un int pero sin establecer explícitamente un valor de retorno, pero eso estaba bien porque las personas que llaman nunca usarían el valor de retorno para estas funciones.

Algunas funciones devolvieron un valor, pero utilizaron implícitamente int porque int era un tipo de devolución adecuado.

Esto significa que el código pre void tenía un montón de funciones que devuelven nominalmente int pero que podrían ser declaradas para volver void y muchas otras funciones que debe devolver un int y no hay forma clara a notar la diferencia. La aplicación de return en todas las rutas de código de todas las funciones que no sean void en cualquier etapa rompería el código heredado.

También existe el argumento de que algunas rutas de código en una función pueden ser inalcanzables, pero esto puede no ser fácil de determinar a partir de un análisis estático simple, entonces ¿por qué imponer un innecesario return?

Answer 2

No es un error porque puede ser el comportamiento previsto. Por ejemplo, algunas bibliotecas de encriptación usan datos locales no inicializados como un paso para la siembra. Como los valores de retorno se guardan en convenciones de llamadas y ubicaciones específicas de plataforma, esto puede ayudar en algunas situaciones inusuales (como las anteriores). En este caso, la función devuelve lo que queda en el registro utilizado para devolver el valor devuelto.

Answer 3

Supongo que es solo una advertencia porque el compilador no siempre puede estar 100% seguro de que es posible no golpear una devolución.

es decir, si tiene que:

-= source1.c =- 
int func() 
{ 
    if(doSomething()) 
    { 
     return 0; 
    } 
} 

-= source2.c =- 
int doSomething() 
{ 
    return 1; 
} 

El compilador en este caso podría no ser capaz de saber que siempre llegará a la devolución, pero sí. Por supuesto, esta es una terrible práctica de programación para confiar en saber cómo funciona el código externo.

En cuanto a lo que realmente se devolverá depende de la plataforma. En los ABI x86, EAX se utiliza para el valor de retorno (hasta 32 bits), por lo que devolverá lo que se haya colocado en ese registro (que podría ser un retorno de otra cosa, un valor temporal o una pérdida total).

Answer 4

aquí es otra razón por la que no es un error

la siguiente información le dará la misma advertencia ya que el compilador espera que devuelva algo del bloque catch a pesar de que usted está lanzando no

int foo(){ 
    try{ 
     return bar(0); 
    } catch(std::exception& ex){ 
     //do cleanup 
     throw ex; 
    } 
} 

int bar(unsigned int i){ 
    if(i == 0){ 
     throw std::string("Value must be greater than 0"); 
    } else{ 
     return 0; 
    } 
} 

Answer 5

Técnicamente no se garantiza que sea un error si llama a una función y esa función siempre arroja una excepción. Por ejemplo, aquí hay un pseudo código, y sabes que raiseError siempre arroja.

MyClass func(params) 
{ 
    if(allIsValid()) 
    { 
     return myObject; 
    } 
    else 
    { 
     raiseError(errorInfo); 
    } 
} 

Si el compilador no puede ver la implementación de raiseError, no va a saber que la función va a lanzar. Entonces realmente no hay un comportamiento indefinido aquí. Por supuesto, es bueno silenciar el compilador aquí, lo cual se puede hacer escribiendo una declaración de devolución "ficticia" después de raiseError, o un "throw" ficticio. Los llamo "tontos" porque nunca serán alcanzados en la realidad. (También puede suprimir la advertencia si realmente insiste). Sin embargo, no hay ningún error o comportamiento indefinido.

Answer 6

cuenta la situación siguiente:

UINT GenderID(GENDER gender) 
{ 
    switch(gender) 
    { 
    case MALE: 
     return MALE_ID; 
    case FEMALE: 
     return FEMALE_ID; 
    } 
// default not required because [GENDER] in our 'Matrix' CAN be either M or F 
} 

un compilador C++ debe permitirá tiene su 'matriz' a su manera; Por lo tanto, no es un error.

Answer 7

Otro ejemplo en el que puede ser un problema para algunas rutas de control que no devuelven un valor:

enum E : int {A, B}; 

int foo(E e) { 
    switch (e) { 
    case A: return 30; 
    case B: return 50; 
    } 
} 

Es posible que e no habrá A o B, pero la implicación es que siempre será uno de esos valores. Si ese es el caso, entonces el código está bien y no hay problema. Convertir esta advertencia en un error obligatorio requeriría un desorden innecesario e "inalcanzable".

Si desea que la advertencia sea un error de todos modos, puede configurar su compilador para hacer eso con un indicador como/WX o -Werror. Aunque, por supuesto, debe tener en cuenta que los diferentes compiladores pueden hacer diferentes determinaciones sobre lo que no se puede alcanzar, por lo que puede estar arreglando cosas diferentes para compiladores diferentes.