c - 82e10193 - ¿Por qué devolver un error negativo?(por ejemplo, retorno-EIO)
error c-82e10193 (4)
Otro ejemplo simple:
if (wpa_s->mlme.ssid_len == 0)
return -EINVAL;
¿Por qué el unario menos? ¿Se hace esto (generalmente) para las funciones que devuelven> 0 en caso de éxito y <(=) 0 en caso de fallo, o hay alguna otra razón?
Desde una perspectiva de optimización, el uso de números negativos permite que los núcleos basados en Unix comprueben un código de error utilizando solo una comparación en lugar de dos.
Las funciones en el núcleo con frecuencia devuelven códigos de error en lugar de punteros. Esto significa que los códigos de error no pueden superponerse con direcciones de puntero válidas, por lo que básicamente deberían ser los valores sin signo más bajos (>= 0) o los más altos (<= unsigned max) .
La comprobación de valores de puntero para NULL y para códigos de error son operaciones extremadamente comunes, por lo que tiene sentido optimizarlos.
Por lo general, los valores inferiores < 0x8000 son NULL y los valores superiores son códigos de error (recuerde que -1 se almacena como 0xff...ff , el máximo valor sin signo posible).
Esto significa que puedes usar una comparación para verificar cada una de ellas:
NULL si x <= 0x8000 (verdadero para 0 a 0x8000)
ERRNO si x >= (unsigned long)(-MAX_ERRNO) (verdadero para -1 a -MAX_ERRNO)
Esas son básicamente las razones. Muchas funciones tienen muchos resultados positivos "buenos", por lo que deja los valores negativos para los códigos de error.
Los códigos de error de C / POSIX son un poco "crecidos históricamente", por lo que no tiene mucho sentido tratar de atribuirles demasiada rima o razón.
Muchos más idiomas modernos lanzan excepciones a los errores para que no tengan que secuestrar parte de su posible rango de respuesta para los códigos de error. Por supuesto, hay compensaciones de cualquier manera.
Primero, esto no es realmente una cosa C Estás viendo una función que está escrita en C para algún propósito. Las mismas convenciones podrían ser utilizadas en cualquier idioma.
En mis viejos días de Unix, había una especie de convención de que 0 significaba éxito, un número positivo significaba problemas menores y un número negativo significaba algún tipo de falla. Por lo tanto, también hubo una especie de convención de if (foo() >= 0) { /* success of a sort */ } .
Esto sin duda estaba relacionado con los códigos de retorno del proceso Unix, donde 0 fue un éxito.
Su comprensión es ampliamente correcta. La interpretación obvia es la correcta.
Sin embargo, la convención estándar es ligeramente diferente a su fórmula.
En Unix, un programa que sale con 0 pruebas de estado como verdadero o exitoso para las utilidades de nivel de CLI como el shell. En la biblioteca, -1 suele ser un error de retorno.
Esto conduce a un paradigma general donde >= 0 significa bueno y < 0 significa error. Nada de esto está escrito en piedra.
Por cierto, esto podría clasificarse como el patrón centinela y podría llamarlo un retorno centinela. En realidad, es una combinación de un "valor" de centinela y un código de error, y es más fácil de escribir y de hacer más seguro para subprocesos que devolver un código de error en un lugar y un valor de centinela para error en otro.
Wikipedia informa que se usa un valor de centinela para terminar un ciclo, pero creo que el retorno de una función sería una instancia mucho más común. Nadie está precisamente a cargo de estas definiciones.