Cierre y puente al próximo curso

1. El punto de llegada

En el tema 1, el primer programa fue este:

#include <stdio.h>

int main(void)
{
    printf("Hola, sistema operativo\n");
    return 0;
}

Estas son cuatro líneas de cuenta, la herramienta del tema 41. Al comienzo del curso habrían sido un jeroglífico; ahora cada pieza tiene una razón:

ssize_t n = read(fd, buf, sizeof buf);

if (n < 0) {
    if (errno == EINTR)
        continue;
    return errno;
}
if (n == 0)
    break;
contador_alimentar(&k, buf, (size_t)n);

Entre un programa y el otro no hay una lista de funciones memorizadas: hay un modelo. Sabes lo que es una dirección y qué ocurre cuando se la usa mal, de dónde sale la memoria de cada variable, qué hace cada etapa de gcc y el enlazador, qué significa que una llamada falle y cómo detectarlo, y cómo averiguar la causa de un error con un depurador. Con eso, el código en C de otras personas deja de ser una caja negra, y el propio deja de ser una apuesta.

Las habilidades del curso se apilan, cada una sobre las anteriores:

2. El curso en diez respuestas

Cada bloque respondió una pregunta. Estas son las respuestas, en una frase cada una:

3. Las ideas que sostienen todo

La sintaxis se olvida, y se vuelve a buscar. Estas diez ideas no se olvidan, porque explican por qué C es como es y por qué los programas en C bien hechos se parecen entre sí. Si alguna no resulta evidente, el tema indicado es el que conviene repasar.

Las cuatro últimas son la diferencia entre un programa que funciona y uno en el que se puede confiar. Ninguna depende de C: valen para cualquier programa que vaya a ejecutarse sin que nadie lo mire, y las volverás a encontrar en los servicios del sistema y en cualquier lenguaje que uses después.

4. Los patrones que se repiten

A lo largo del curso, las mismas formas aparecieron en programas muy distintos. Reconocerlas es lo que permite escribir uno nuevo sin empezar de cero, y leer uno ajeno sin perderse.

5. Los errores, ahora con explicación

Los mensajes de gcc, del enlazador, del cargador y del sistema son breves y, al principio, crípticos. Pero casi siempre dicen exactamente qué pasó. Al comienzo del curso eran frases en inglés; ahora cada una remite a un mecanismo conocido.

La costumbre que resume la tabla es la del tema 4: leer el mensaje completo, con su archivo y su línea, antes de cambiar nada; y compilar con -Wall -Wextra para que el compilador diga lo que sospecha antes de que el programa se ejecute.

6. La caja de herramientas

El inventario del curso, ordenado por lo que se quiere hacer. No es para memorizar: es para saber que la herramienta existe, y dónde está explicada.

7. Lo que quedó en tu equipo

Si hiciste los ejemplos, tienes ahora una colección de programas y de plantillas que siguen siendo útiles, y que forman entre todos una pequeña base de trabajo:

Conviene guardarlo todo en un repositorio de git, con su historia. Es el hábito que convierte ejercicios sueltos en un portafolio, y lo que hace falta para que alguien más (o tú, dentro de un año) pueda construirlo con un solo make.

8. Lo que quedó sin ver

Un curso elige. Varios temas se nombraron y se dejaron a un lado, a propósito, para no perder el hilo. Conviene saber cuáles son:

9. La ruta: once cursos más

Este curso es el cuarto de una serie de quince. Enseñó el lenguaje del sistema: con él se escribieron los programas que el curso de Bash solo podía llamar. Los que siguen bajan, curso a curso, hacia lo que el sistema operativo hace por dentro, y casi todos retoman algo que aquí se usó sin explicar cómo funciona.

Nivel inicial

Nivel intermedio

Nivel avanzado

Un kernel está escrito en C, y el último curso de la serie lo vuelve a usar: sin la biblioteca estándar, con el enlazador configurado a mano y los errores sin ninguna red. Todo lo del bloque 8 del curso, el enlazador, los símbolos y las bibliotecas, es el vocabulario de esa etapa.

10. El próximo paso: Procesos e Hilos

El curso que sigue es Procesos e Hilos. Hasta aquí, cada programa fue un proceso solitario: se lo lanza, hace su trabajo y termina. El curso siguiente enseña cómo un programa crea otros, cómo se comunican con el que los lanzó, cómo se espera a que terminen, y cómo un solo proceso puede hacer varias cosas a la vez con hilos. Sus ejemplos están escritos en C, y lo que el curso actual dejó listo se retoma casi tema por tema:

La diferencia con este curso es de ámbito. Aquí un programa pedía cosas al sistema y esperaba la respuesta; allí un programa crea otros programas, y el sistema decide cuándo corre cada uno. Es más difícil de razonar, porque el orden en que ocurren las cosas deja de ser el del código, y es justamente por eso que importan las herramientas que aprendiste: gdb para detenerse en medio, strace para ver qué llama cada proceso, los sanitizadores para encontrar las carreras, y las pruebas con casos de borde.

Llegas con ventaja. Quien empieza procesos e hilos sin saber manejar errores, sin entender los búferes de stdio ni la memoria de un proceso tiene que aprender todo a la vez, y tropieza con los efectos antes de conocer las causas. Tú ya sabes qué hace cada una de esas piezas por separado.

11. Cómo seguir practicando

C se aprende como cualquier lenguaje: escribiendo y leyendo mucho. Algunas maneras, de menor a mayor esfuerzo:

• Reescribir las herramientas pequeñas de Unix. cat, head, tail, grep, hexdump, cp, sort, wc (ya lo hiciste con cuenta). Cada una tiene una referencia contra la cual comparar, y cada una obliga a pensar en archivos, errores y casos de borde.
• Compilar siempre con todas las defensas. -Wall -Wextra -Wshadow -Wconversion y un modo con -fsanitize=address,undefined. Cada aviso que no entiendas es un tema para repasar.
• Escribir una biblioteca de estructuras de datos (lista, tabla de dispersión, arreglo dinámico) con su archivo de pruebas, sus casos de borde y los sanitizadores en cada ejecución. Es el mejor ejercicio de memoria que existe.
• Leer código de otros. Hay proyectos pequeños y muy bien escritos: las herramientas del sistema (coreutils, BusyBox), SQLite, o una biblioteca como zlib. Leer cómo organizan las cabeceras, los errores y la memoria enseña más que muchos libros.
• Depurar con gdb sin avergonzarse. Cuando algo falle, antes de poner printf, probar run, bt, print. La práctica diaria es lo que lo vuelve natural.
• Contribuir a un proyecto de código abierto con un arreglo pequeño: un aviso del compilador, una prueba que falta, un error de documentación. Es la manera de ver C de producción.

Para quien quiera textos de consulta más amplios:

Y antes que cualquier libro, la documentación que ya está en tu máquina: man 2 para las llamadas al sistema, man 3 para las funciones de la biblioteca de C, info make y el manual de gdb, que ahora puedes leer con soltura.

12. El curso, en doce frases

• C es el lenguaje del sistema: da control directo sobre la máquina y a cambio pide al programador la disciplina que otros lenguajes ponen por él.
• El camino del fuente al ejecutable son cuatro etapas, y cada error pertenece a una: preprocesador, compilador, ensamblador o enlazador.
• Los tipos tienen un tamaño y un signo; las operaciones pueden desbordarse o convertirse sin avisar, y el comportamiento indefinido no se anuncia.
• Una función recibe copias, vive en un marco de la pila y se declara en un .h; lo interno se esconde con static.
• Un puntero es una dirección con tipo; un arreglo, al pasarlo a una función, se convierte en un puntero y pierde su tamaño, que debe viajar aparte.
• Una cadena es un arreglo de bytes terminado en un nulo, y las funciones que no miran el tamaño son la causa de casi todo desbordamiento.
• Una estructura tiene relleno por alineación; una unión, una enumeración y un typedef dan forma y nombre a los datos propios.
• La memoria dinámica se pide, se comprueba y se libera una sola vez, con un dueño claro para cada bloque; Valgrind y AddressSanitizer encuentran los errores que el compilador no ve.
• Un proyecto se arma con archivos objeto y bibliotecas estáticas o dinámicas, y make reconstruye solo lo que cambió, con las dependencias que el compilador informa.
• Toda llamada puede fallar: se comprueba el valor de retorno, se guarda errno enseguida, se escribe un mensaje por stderr y se sale con un código con sentido.
• Entre el programa y el disco hay búferes: lo que no se vacía puede perderse, y fclose es una operación que también falla.
• Una herramienta de verdad se especifica antes, se organiza en biblioteca y programa, se prueba en sus bordes y contra una referencia, y se compila con avisos estrictos, sanitizadores y gdb a mano.

13. Autoevaluación final

Estas preguntas no corresponden a un tema: cada una pide relacionar varios. Si puedes responderlas sin consultar, el objetivo del curso está cumplido.

Para terminar

1. Vuelve al tema 1 y reescribe hola.c como una herramienta: una opción -n NOMBRE con getopt, su ayuda, un mensaje de error por stderr con código de sysexits.h si falta un argumento, un Makefile con los tres modos y una prueba de integración. ¿Cuántos temas del curso usaste?
2. Elige las tres ideas de la sección 3 que te resulten menos claras, y repasa los temas indicados.
3. Recorre la tabla de errores de la sección 5 y provoca cada uno a propósito en un programa de prueba, comprobando el mensaje y el código de salida.
4. Pasa por los sanitizadores y por -fanalyzer todos los programas que escribiste durante el curso, y corrige lo que señalen. Anota qué errores encontraste.
5. Toma una herramienta pequeña de Unix que uses todos los días (head, tail, hexdump…) y construye tu propia versión siguiendo el modelo del tema 41: especificación, biblioteca, programa, pruebas contra la referencia, Makefile y los tres modos.
6. Lee la primera página del curso siguiente, Procesos e Hilos, y anota qué conceptos de este curso necesitarás en cada bloque.

Aquí termina Programación en C para Sistemas Operativos. Empezó con un saludo impreso por un programa de una sola función, y termina con una herramienta que cuenta, se prueba contra una referencia, se compila en tres modos y avisa de sus errores con un código que otro programa puede entender. Lo que cambió no es la cantidad de código sino lo que sabes de él: de dónde sale cada byte de memoria, qué ocurre en cada etapa de la compilación, cómo falla una llamada al sistema y cómo averiguar por qué. Con eso, los programas dejan de ser un misterio y empieza lo que sigue: hacerlos nacer, convivir y trabajar juntos.