Por qué C para sistemas operativos

1. Programas en C que ya usaste

En el curso de Bash escribiste cientos de líneas para la shell. Pero la shell misma es un programa, y se puede preguntar qué clase de archivo es:

$ file /usr/bin/bash
/usr/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a292b52b…, for GNU/Linux 3.2.0, stripped
$ ldd /usr/bin/bash
	linux-vdso.so.1 (0x00007ffd6f1dd000)
	libtinfo.so.6 => /usr/lib/x86_64-linux-gnu/libtinfo.so.6 (0x0000759f3438c000)
	libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x0000759f34000000)
	/lib64/ld-linux-x86-64.so.2 (0x0000759f3454d000)

No es un texto como un script, sino un ejecutable ELF: instrucciones de máquina para un procesador x86-64, en el formato que entiende Linux. Fue escrito en C, compilado, y depende de unas pocas bibliotecas compartidas, entre ellas libc.so.6, la biblioteca de C del sistema. Todo eso, el formato ELF, las bibliotecas compartidas, el cargador ld-linux que las une al arrancar, es tema de este curso.

Lo mismo ocurre con casi todo lo que hay debajo de la terminal: el núcleo Linux, la biblioteca de C, systemd, el servidor SSH, gzip, tar, rsync, el propio compilador de C. Hay excepciones, y van en aumento: algunas distribuciones recientes reemplazaron los comandos básicos como ls por versiones escritas en Rust, y el núcleo admite desde 2022 partes en ese lenguaje. Pero incluso esos programas, al final, le hablan al sistema a través de la biblioteca de C y de interfaces definidas en C. Quien quiera entender cómo funciona un sistema operativo tiene que poder leer C.

2. Qué es C

C es un lenguaje de programación compilado, imperativo y de propósito general, diseñado para escribir sistemas operativos. Sus programas se traducen a instrucciones de máquina antes de ejecutarse, y le dan al programador acceso directo a la memoria a través de direcciones, con muy poca maquinaria entre el código y el procesador.

Cada palabra de esa definición tiene consecuencias que veremos a lo largo del curso:

• Compilado: un programa, el compilador, traduce el código fuente a un ejecutable una sola vez. Lo que se ejecuta después ya no necesita al compilador ni al código fuente, a diferencia de un script, que Bash lee y ejecuta línea por línea cada vez.
• Imperativo: el programa es una secuencia de órdenes que cambian el estado de la memoria, una tras otra, como un script de Bash.
• Acceso directo a la memoria: una variable es un lugar con una dirección, y C permite conocer esa dirección, guardarla, hacer cuentas con ella y leer o escribir lo que hay allí. Es el tema de los bloques 4 a 7.
• Poca maquinaria: no hay un recolector de basura que libere la memoria olvidada, ni comprobaciones de que un índice esté dentro de un arreglo, ni excepciones. Lo que el programa no hace explícitamente, no ocurre.

Se suele decir que C es un lenguaje «de bajo nivel», y es cierto comparado con Python o con Bash. Pero es de más alto nivel que el lenguaje ensamblador: tiene variables con tipo, funciones, estructuras y bucles, y el mismo programa puede compilarse para procesadores muy distintos. Esa combinación, cerca de la máquina y a la vez independiente de una máquina en particular, es la razón de su éxito.

3. Una historia compartida con Unix

C y Unix nacieron juntos, en los Laboratorios Bell de AT&T, y cada uno se hizo a la medida del otro:

En 1969, Ken Thompson escribió la primera versión de Unix en el lenguaje ensamblador de una pequeña computadora, la PDP-7. El ensamblador es la forma legible de las instrucciones de un procesador concreto, y tiene un problema: un sistema escrito en él solo funciona en ese procesador, y para llevarlo a otro hay que reescribirlo entero. Thompson creó entonces un lenguaje más cómodo, B, y Dennis Ritchie lo extendió con tipos de datos y estructuras para aprovechar las máquinas más nuevas. El resultado, hacia 1972, fue C.

El paso decisivo llegó en 1973: el núcleo de Unix se reescribió en C. Era una idea audaz, porque se creía que un sistema operativo solo podía escribirse en ensamblador para ser lo bastante rápido. Funcionó, y cambió la historia: por primera vez, llevar un sistema operativo a una computadora nueva no exigía reescribirlo, sino escribir un compilador de C para esa máquina y adaptar las pocas partes que dependían del hardware. Unix se extendió a universidades y empresas, y C con él.

En 1978, Brian Kernighan y Dennis Ritchie publicaron The C Programming Language, conocido como «K&R», que durante años fue la definición del lenguaje. En 1989 llegó el primer estándar oficial, ANSI C, y desde entonces el lenguaje se revisa cada tantos años. En 1991, Linus Torvalds empezó a escribir Linux, un núcleo nuevo con la forma de Unix, en C. Medio siglo después, el lenguaje sigue siendo el mismo en lo esencial: un programa de los años ochenta, con pocos cambios, compila hoy.

4. Por qué los sistemas operativos se escriben en C

Un sistema operativo tiene necesidades que la mayoría de los programas no tiene. C las cubre todas, y por eso, cincuenta años después, sigue siendo la elección por defecto:

El último punto merece atención. Python, Rust, Go y Java pueden llamar a funciones escritas en C, porque la forma en que C pasa los argumentos y devuelve los resultados es un acuerdo que respetan todos. Por eso la frontera entre los programas y el sistema operativo, y entre lenguajes distintos, se define casi siempre en C. Aunque escribas tus programas en otro lenguaje, cuando hablen con el sistema estarán hablando en C.

5. El primer programa

Por tradición, desde el libro de Kernighan y Ritchie, el primer programa en C muestra un saludo. Este es el nuestro:

#include <stdio.h>

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

$ gcc -Wall -Wextra -o hola hola.c
$ ./hola
Hola, sistema operativo
$ echo $?
0
$ ls -l hola.c hola
-rwxr-xr-x 1 ana ana 15952 oct 15 10:22 hola
-rw-r--r-- 1 ana ana    94 oct 15 10:22 hola.c

En el tema 3 lo leeremos línea por línea; por ahora alcanza con lo esencial. #include <stdio.h> trae las declaraciones de la biblioteca de entrada y salida, donde está printf. main es la función por la que empieza todo programa en C. Y el return 0 final es el código de salida que el programa le devuelve a quien lo ejecutó: el mismo $? que usaste en todos los scripts del curso de Bash. Un script que llama a un programa en C se entera así de si funcionó.

gcc es el compilador: lee hola.c y produce hola, un ejecutable de casi dieciséis mil bytes a partir de un fuente de noventa y cuatro. La diferencia no es el saludo: es todo lo que hace falta para que el sistema pueda cargar y arrancar el programa, y para que encuentre printf en la biblioteca de C. Las opciones -Wall -Wextra piden al compilador que advierta todo lo que parezca un error, y las usaremos siempre. El tema 4 sigue paso a paso el camino del fuente al ejecutable.

6. Ver la memoria desde un programa

Lo que distingue a C se ve en cuanto un programa pregunta dónde están sus propios datos. Este muestra el valor de dos variables, cuánto ocupan y en qué dirección de memoria viven, y lo mismo para una variable global y para el propio código de main:

#include <stdio.h>

int contador = 7;

int main(void)
{
    int edad = 30;
    char inicial = 'A';

    printf("edad    vale %d, ocupa %zu bytes y vive en %p\n", edad, sizeof edad, (void *) &edad);
    printf("inicial vale %c, ocupa %zu byte  y vive en %p\n", inicial, sizeof inicial, (void *) &inicial);
    printf("contador vale %d y vive en %p\n", contador, (void *) &contador);
    printf("el código de main empieza en %p\n", (void *) main);
    return 0;
}

$ gcc -Wall -Wextra -o memoria memoria.c
$ ./memoria
edad    vale 30, ocupa 4 bytes y vive en 0x7ffed608d3a4
inicial vale A, ocupa 1 byte  y vive en 0x7ffed608d3a3
contador vale 7 y vive en 0x558354925010
el código de main empieza en 0x558354922169
$ ./memoria
edad    vale 30, ocupa 4 bytes y vive en 0x7fff04021ed4
inicial vale A, ocupa 1 byte  y vive en 0x7fff04021ed3
contador vale 7 y vive en 0x56860c8a8010
el código de main empieza en 0x56860c8a5169

Hay mucho que leer en esas ocho líneas, y cada cosa tiene su tema en el curso:

• Cada dato ocupa una cantidad exacta de bytes: un int, 4; un char, 1. sizeof lo dice, y en el tema 5 veremos por qué importa.
• Cada dato tiene una dirección, que & obtiene y %p muestra en hexadecimal. Una variable que guarda una dirección es un puntero, el centro del bloque 4.
• Las variables viven en zonas distintas: edad e inicial, declaradas dentro de main, están juntas, una byte al lado de la otra, en direcciones que empiezan con 0x7ff…, la pila. contador, declarada afuera, y el código de main están en otra zona, cerca uno del otro. Es el mapa de memoria de un proceso, del tema 27.
• Las direcciones cambian en cada ejecución. El sistema coloca cada zona en un lugar al azar cada vez que arranca un programa, una protección llamada ASLR (Address Space Layout Randomization) que dificulta los ataques. Las distancias dentro de cada zona, en cambio, se mantienen: contador está siempre 0x2ea7 bytes después del código de main.

Ningún programa en Bash puede preguntar estas cosas. En C son lo primero que se aprende a mirar, porque la memoria es la materia con la que se trabaja.

7. Lo que C ofrece

8. Lo que C exige a cambio

La otra cara de esa libertad es que C confía en el programador por completo, y no lo protege de sus errores. Este programa tiene uno muy común: el bucle recorre un arreglo de tres elementos, pero la condición i <= 3 deja que i llegue a 3, una posición más de las que existen:

#include <stdio.h>

int main(void)
{
    int notas[3] = {7, 9, 10};
    int otra = 1234;

    for (int i = 0; i <= 3; i++)          /* error: i llega a 3 */
        printf("notas[%d] = %d\n", i, notas[i]);
    printf("otra = %d\n", otra);
    return 0;
}

$ gcc -Wall -Wextra -o fuera fuera.c
$ ./fuera
notas[0] = 7
notas[1] = 9
notas[2] = 10
notas[3] = -448843008
otra = 1234
$ echo $?
0

El compilador no advirtió nada, el programa no se detuvo, no hubo ningún mensaje de error, y terminó con código 0, como si todo estuviera bien. notas[3] leyó los cuatro bytes que había en la memoria justo después del arreglo, fueran lo que fueran, y los mostró como un número. En Python, el mismo error produce un IndexError inmediato. En C, el programa sigue adelante con un dato inventado. Y si en lugar de leer hubiera escrito, habría modificado otra variable, o algo peor, sin que nadie se enterara.

No estamos indefensos, sin embargo. El compilador detecta este caso concreto si se le pide optimizar, porque entonces analiza el bucle con más cuidado; y una herramienta de diagnóstico, AddressSanitizer, incorporada en gcc, agrega al programa comprobaciones que lo detienen en el acceso exacto:

$ gcc -O2 -Wall -Wextra -o fuera fuera.c
fuera.c: In function ‘main’:
fuera.c:9:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
    9 |         printf("notas[%d] = %d\n", i, notas[i]);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fuera.c:8:23: note: within this loop
    8 |     for (int i = 0; i <= 3; i++)          /* error: i llega a 3 */
      |                     ~~^~~~
$ gcc -g -fsanitize=address -o fuera fuera.c
$ ./fuera
notas[0] = 7
notas[1] = 9
notas[2] = 10
=================================================================
==491==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x733399dd002c …
READ of size 4 at 0x733399dd002c thread T0
    #0 0x6474b59943e6 in main /home/ana/c/fuera.c:9
…
  This frame has 1 object(s):
    [32, 44) 'notas' (line 5) <== Memory access at offset 44 overflows this variable

La advertencia de la optimización usa una expresión que aparecerá mucho, undefined behavior, comportamiento indefinido, y AddressSanitizer dice exactamente qué pasó: una lectura de 4 bytes justo después del final de notas, en la línea 9. Aprender C es, en buena medida, aprender a usar estas herramientas, que veremos en los temas 29, 39 y 40. Estas son las responsabilidades que C deja en tus manos:

9. El comportamiento indefinido

El estándar de C llama comportamiento indefinido a lo que ocurre cuando un programa hace algo que el lenguaje prohíbe pero no está obligado a detectar, como leer fuera de un arreglo. El estándar no promete nada sobre el resultado: el programa puede dar un valor absurdo, detenerse, parecer funcionar perfectamente, o comportarse distinto con otro compilador o con otras opciones.

Es el concepto más importante, y más traicionero, de C. Un programa con comportamiento indefinido no está «casi bien»: está mal, aunque las pruebas pasen. Un ejemplo clásico es el desbordamiento de un entero con signo:

#include <stdio.h>
#include <limits.h>

int main(void)
{
    int x = INT_MAX;
    printf("INT_MAX     = %d\n", x);
    printf("INT_MAX + 1 = %d\n", x + 1);
    unsigned int u = UINT_MAX;
    printf("UINT_MAX + 1 = %u\n", u + 1);
    return 0;
}

$ gcc -Wall -Wextra -o desborde desborde.c
$ ./desborde
INT_MAX     = 2147483647
INT_MAX + 1 = -2147483648
UINT_MAX + 1 = 0
$ gcc -fsanitize=undefined -o desborde desborde.c && ./desborde
desborde.c:8:5: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
…

La salida parece razonable: el número «da la vuelta» y se vuelve negativo. Pero para un int, que tiene signo, ese resultado es casualidad: el estándar dice que el desbordamiento es indefinido, y el compilador tiene derecho a suponer que nunca ocurre, lo que puede hacer que una comprobación como if (x + 1 < x) desaparezca al optimizar. Para un unsigned int, en cambio, la vuelta a cero está definida y garantizada. El sanitizador de comportamiento indefinido, -fsanitize=undefined, lo detecta en tiempo de ejecución. Estos son los casos más frecuentes, cada uno con su tema:

10. C y el sistema operativo

Un programa en C no puede escribir en la pantalla por sí mismo, ni abrir un archivo, ni pedir memoria: todo eso lo hace el núcleo, y el programa se lo pide con una llamada al sistema. La herramienta strace, que muestra cada llamada al sistema de un programa, deja ver qué hizo realmente hola:

$ strace ./hola 2>&1 | tail -n 6
brk(NULL)                               = 0x5622a618b000
brk(0x5622a61ad000)                     = 0x5622a61ad000
write(1, "Hola, sistema operativo\n", 24Hola, sistema operativo
) = 24
exit_group(0)                           = ?
+++ exited with 0 +++

El printf del programa terminó convertido en write(1, "Hola, sistema operativo\n", 24): escribir 24 bytes en el descriptor 1, la salida estándar de la que tanto hablamos en los cursos anteriores. Y el return 0, en exit_group(0), que le entrega al núcleo el código de salida. Las brk anteriores piden memoria para el buffer de printf. En total, este programa de dos líneas hizo 34 llamadas al sistema, casi todas para que el cargador preparara el proceso antes de llegar a main.

Entre el programa y el núcleo hay una capa intermedia, la biblioteca de C, que en Linux es casi siempre la de GNU, glibc: el libc.so.6 que mostraba ldd. Ofrece dos tipos de funciones, que el manual separa en secciones distintas:

En este curso usaremos sobre todo las de la sección 3, y en el tema 38 veremos las dos formas de trabajar con archivos, una sobre cada capa. Los cursos siguientes, empezando por Procesos e Hilos, viven en la sección 2.

11. C frente a otros lenguajes

C no es la mejor elección para todo, y conviene saber cuándo no lo es. Esta comparación, simplificada, ubica a C entre los lenguajes que probablemente conoces o conocerás:

Rust merece una mención especial, porque fue creado precisamente para resolver los problemas de la sección 8: su compilador rechaza los programas que podrían acceder a memoria inválida. Por eso está entrando, de a poco, en terrenos que eran exclusivos de C, como el núcleo Linux y los comandos básicos de algunas distribuciones. Pero C sigue siendo el idioma común: las interfaces del sistema se definen en C, la enorme mayoría del código existente está en C, y entender C es la base para entender por qué existe Rust. Lo que aprendas aquí sobre la memoria vale para cualquier lenguaje de sistemas.

12. Las versiones del lenguaje

C está definido por un estándar internacional, ISO/IEC 9899, que se revisa cada tantos años. Cada versión agrega cosas sin romper los programas anteriores:

Los compiladores eligen una versión por omisión, que cambia con el tiempo; gcc 15, por ejemplo, usa C23 con extensiones propias de GNU. Para que los ejemplos del curso funcionen igual con compiladores de distintas épocas, compilaremos con -std=c17, y señalaremos lo que cambia en C23 cuando aparezca.

Hay además un segundo estándar que nos acompañará: POSIX, que no define el lenguaje sino la interfaz de los sistemas de la familia Unix. printf y malloc son de C, y existen en cualquier sistema; write, open o getopt son de POSIX, y existen en Linux, macOS y los demás Unix, pero no necesariamente en otros sistemas.

13. Cómo trabajaremos

Todos los ejemplos del curso están desarrollados y probados en Linux con gcc. Para seguirlos hace falta un sistema Linux, real, en una máquina virtual o en WSL, con las herramientas de desarrollo instaladas:

$ sudo apt install build-essential gdb valgrind strace
# build-essential incluye gcc, make y la biblioteca de C con sus encabezados

En el tema 2 preparamos el entorno con detalle. Desde ya, cuatro costumbres que valen para todo el curso:

1. Compilar siempre con las advertencias encendidas: -Wall -Wextra, y tratar cada advertencia como un error hasta entenderla. El compilador es el primer revisor de tu código. advertencias
2. Compilar a menudo, cada pocas líneas, en lugar de escribir cien y descubrir veinte errores juntos. pasos cortos
3. Probar con los sanitizadores mientras se desarrolla: -fsanitize=address,undefined convierte el comportamiento indefinido silencioso en un mensaje claro. sanitizadores
4. Consultar el manual: man 3 printf y man 2 write dicen exactamente qué hace cada función, qué devuelve y cómo informa los errores. manual

Y la automatización del curso anterior sigue siendo útil: el build.sh del tema 36 de Bash, o un Makefile, que aprenderás a escribir en el bloque 8, compilan y prueban un programa con una sola orden.

14. El mapa del curso

Los 42 temas están ordenados para que cada bloque se apoye en los anteriores. Cada uno responde una pregunta:

Los bloques 2 y 3 enseñan lo que C comparte con casi todos los lenguajes, y van rápido si ya programaste. Los bloques 4 a 7 son el corazón del curso: lo que hace a C distinto, y lo que más se usa en los cursos siguientes. El 8 enseña a construir programas reales, y el 9, a encontrar lo que falla en ellos.

15. Resumen

• El núcleo Linux, la biblioteca de C, la shell y la mayoría de los comandos del sistema están escritos en C; son ejecutables ELF que dependen de libc.so.6.
• C es un lenguaje compilado e imperativo, con acceso directo a la memoria y muy poca maquinaria entre el código y el procesador.
• C nació hacia 1972 junto con Unix, y en 1973 el núcleo de Unix se reescribió en C, lo que permitió llevarlo a otras máquinas sin reescribirlo. Linux, de 1991, también está escrito en C.
• Los sistemas operativos se escriben en C porque permite controlar la memoria, no necesita un entorno de ejecución, es rápido y predecible, habla con el hardware y existe para cualquier procesador.
• gcc -Wall -Wextra -o hola hola.c compila un programa; el return de main es su código de salida, el $? de la shell.
• Cada dato en C ocupa una cantidad de bytes conocida y tiene una dirección; las direcciones cambian en cada ejecución por ASLR.
• C no comprueba los índices, ni la memoria liberada, ni los punteros: un error puede no producir ningún mensaje.
• El comportamiento indefinido es lo que ocurre cuando un programa viola las reglas del lenguaje: el estándar no promete nada, aunque el programa parezca funcionar.
• Las advertencias del compilador, AddressSanitizer y -fsanitize=undefined detectan muchos de esos errores.
• Los programas le piden servicios al núcleo con llamadas al sistema, documentadas en la sección 2 del manual; la biblioteca de C, de la sección 3, las envuelve.
• El curso usa C17 sobre Linux, con gcc, y presta atención a POSIX, la interfaz de los sistemas Unix.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Ejecuta file y ldd sobre varios programas de tu sistema: bash, gzip, ssh, python3. ¿Cuáles dependen de libc.so.6? Si alguno es un script, ¿qué intérprete indica file?
2. Compila y ejecuta hola.c. Cambia el return 0 por return 3, vuelve a compilar y comprueba el valor de $?. Prueba también ./hola && echo funcionó con cada valor.
3. Compila memoria.c y ejecútalo varias veces. Calcula la distancia entre las direcciones de edad e inicial, y entre contador y main. ¿Cuáles se mantienen?
4. Compila fuera.c sin opciones, con -O2 -Wall y con -fsanitize=address, y compara lo que ocurre en cada caso. Luego cambia el bucle para que escriba en notas[3] en lugar de leer, y observa el valor de otra.
5. Ejecuta strace -c ./hola y strace -c ls. ¿Cuántas llamadas al sistema hace cada uno? ¿Cuáles aparecen en ls que no aparecen en hola?
6. Lee man 3 printf y man 2 write, y anota qué devuelve cada función y cómo informa un error.