Este código hace una falla de segmentación:
int main(int argc, char *argv[]){ int *n; *n = atoi(argv[1]); printf("n: %d \n", *n); return 0; }mientras esto funciona:
int main(int argc, char *argv[]){ int *n; *n = atoi(argv[1]); pid_t pid = fork(); if (pid == 0) return 0; else printf("n: %d \n", *n); return 0; } ¿Por qué funciona el segundo con el tenedor? Sé que después de int *n , debería asignar espacio para un int con un malloc() , pero usar el fork() parece hacer esto automáticamente.
editar: ahora entiendo el comportamiento indefinido :) Pero ahora pregunto: ¿cuál es la causa en este caso específico?
No funciona. (O más precisamente, tienes un comportamiento indefinido)
1) La bifurcación solo oculta la falla de segmento, porque no está verificando el código de salida del proceso secundario.
2) La asignación de memoria no es automática, ¡nunca!
Simplemente está escribiendo en una ubicación aleatoria, y puede que tenga "suerte" de que en la segunda versión la ubicación aleatoria esté dentro de su espacio de proceso.
Ambos fragmentos de código invocan un comportamiento indefinido , cortesía,
*nargv[1] (si argc no es >=2 )La falla de segmentación es uno de los muchos efectos secundarios de UB. El caso UB también incluye un escenario que funciona sin problemas .
¿Por qué funciona el segundo con el tenedor?
No tiene nada que ver con la presencia (o ausencia) de fork() UB. TL;DR.
pero usar el fork() parece hacer esto automáticamente.
Las imágenes pueden ser engañosas. No ponga su dinero en UB.
Debido a que n no está inicializado y, por lo tanto, apunta a una dirección de memoria desconocida, está invocando un comportamiento indefinido. Puede fallar (como en el primer ejemplo), o puede que no (como en el segundo ejemplo).
En una situación como esta, algo tan simple como agregar una variable no utilizada puede hacer que un programa se bloquee antes, o viceversa.
Asigne memoria para n y no tendrá ese problema.
Editar:
El hecho de que ejecutar ./test 100 funcione cuando ejecutas el segundo programa, sin importar cuántas veces, es cuestión de suerte. El hecho de que haya agregado una llamada a la fork (en este caso) reorganizó la forma en que se distribuye la memoria para que funcione. Más adelante, puede decidir llamar a printf para una depuración adicional y, de repente, comienza a fallar nuevamente.
Agregar la llamada de fork no asignó automáticamente ningún espacio.
La única forma de evitar un bloqueo es asignar memoria para n y asegurarse de que argc sea al menos 2 para que argv[1] apunte a algún lugar significativo.