Más de una vez hemos puesto rutas absolutas en nuestro código, porque es común no entender cómo funcionan las rutas absolutas dentro de un programa.

Disclaimer: escribí este post hace unos días, a mano, y, ahora que lo estoy releyendo para tipearlo en la compu, no me parece tan genial como cuando lo escribí la primera vez. Recomiendo tomarlo bastante más con pinzas que de costumbre, y donde encuentren algo que les haga ruido – o directamente sientan que lo que digo es incorrecto, o que el enfoque no es bueno – avisen, así lo rewordeo. Por favor, perdón y gracias.

Las variables de C son nombres que refieren a una posición de memoria de la computadora. El compilador traduce cada nombre a una dirección de memoria, y el tamaño de la variable está determinado por su tipo.

Pero si bien el estándar de C pone algunas restricciones a los tamaños de los tipos de datos básicos, no todos tienen igual tamaño en las distintas plataformas, o incluso entre distintos compiladores de C para la misma plataforma.

Este post es mi traducción del post Learning C with GDB de Alan O’Donnell, del blog de Hacker School. La traducción fue hecha con el permiso de Hacker School, y obviamente todos los derechos sobre el post original les pertenecen a ellos. Cualquier error o sugerencia sobre la traducción es más que bienvenida.

Viniendo del mundo de lenguajes de más alto nivel como Ruby, Scheme o Haskell, aprender C puede ser complicado. Además de tener que pelear con las características de bajo nivel de C como el manejo manual de memoria y los punteros, tenés que arreglártelas sin un REPL. Una vez que te acostumbrás a programar explorando en un REPL, tener que lidiar con el ciclo escribir-compilar-correr es bastante un desalentador.

Hace poco se me ocurrió que podría usar gdb como un pseudo-REPL para C. Estuve experimentando el uso de gdb como una herramienta para aprender C, en lugar de simplemente para debuggear C, y está bastante bueno.

Mi objetivo en este post es mostrarte que gdb es una gran herramienta para aprender C. Te voy a mostrar algunos de mis comandos de gdb favoritos, y después te voy a mostrar cómo podés usar gdb para entender una parte bastante complicada de C: la diferencia entre los arrays y los punteros.

Este post es mi traducción del post Understanding C by learning assembly de David Albert, del blog de Hacker School. La traducción fue hecha con el permiso de Hacker School, y obviamente todos los derechos sobre el post original les pertenecen a ellos. Cualquier error o sugerencia sobre la traducción es más que bienvenida.

La última vez, Alan mostró cómo usar GDB como una herramienta para aprender C¹. Hoy quiero ir un paso más allá y usar GDB para ayudarnos a entender assembler, también.

Las capas de abstracción son grandes herramientas para construir cosas, pero a veces pueden interponerse en el aprendizaje. Mi objetivo en este post es convencerte de que para aprender C rigurosamente, también necesitamos entender el código assembler que nuestro compilador de C genera. Voy a hacer esto mostrándote cómo desensamblar y leer un programa simple con GDB, y después vamos a usar GDB y nuestro conocimiento de assembler para entender cómo funcionan las variables locales estáticas en C.

¿Qué es un hard link? ¿Qué es un soft link? ¿Qué diferencia hay entre ellos?

Me parece que la clave para entender los enlaces en los filesystems basados en inodos¹ es entender qué es un archivo.

Este post es un laburo en conjunto que hicimos con Micaela Oriolo. Kudos para ella :)

No entiendo qué pito tocan los uint32. ¿Cuándo hay que usarlos sí o sí?

En la vida real, todo puede explotar. Entre las miles de causas del típico “en casa compila”, se encuentra el uso (o no uso, mejor dicho) de los tipos de datos que especifican su tamaño. En este caso, vamos a hablar del tipo de dato int.

Hace un tiempo me llegó la siguiente consulta por mail:

Cuando trato de correr un proceso por consola me tira un mensaje “violacion de segmento” (‘core’ generado). Como mi proceso compilaba correctamente, no me tira errores, me resultaba extraño que me tire en tiempo de ejecución ese error.

Mi pregunta es, ¿puede ser que los errores del segmentation fault no me los alerte en tiempo de compilacion?

Este post es mi traducción del post A Quick Tutorial on Implementing and Debugging Malloc, Free, Calloc, and Realloc de Dan Luu. Cualquier error o sugerencia sobre la traducción es bienvenida, y si querés que haga de intermediario para sugerirle cambios de contenido a él, también vale.

¡Implementemos nuestro propio malloc y veamos cómo funciona con programas pre-existentes!

Este tutorial asume que sabés qué es un puntero, y que *ptr dereferencia un puntero, y que ptr->foo significa (*ptr).foo, que malloc se usa para reservar (allocar) espacio dinámicamente, y que te es familiar el concepto de lista enlazada. Si decidís seguir este tutorial sin tener un claro conocimiento de C, contame qué partes convendría explicar un poco más. Si querés mirar todo el código de una, está disponible acá.

Con algo de suerte, este será el primero de una serie de al menos 3 posts hablando sobre la gestión de la memoria en C. Sólo parece no aportar tanto, pero probablemente entre los 3 den un mensaje más o menos copado. Stay tuned :)

Una de las complejidades más importantes asociadas a la programación en C es la gestión y el uso de la memoria.

Si alguna vez editaron un script UNIX, seguramente habrán visto que arrancan de manera similar: #!/bin/sh. Por algún motivo, esa línea mágica se llama Shebang¹.

1
2

#!/bin/sh
echo "¡Hola, mundo!"

Llamamos mi_script a este archivo.

Esa línea mágica es la responsable de que podamos correr un script ejecutando ./mi_script en la consola.

Uno de los mecanismos de IPC que nos provee Linux es el envío de señales. Es un modo de comunicación MUY minimalista: un proceso le envía una determinada señal a otro, y este último simplemente recibe el código asociado a la señal recibida.

Y nada más. No hay parámetros, no hay información del emisor, nada. Sólo un código.

**Disclaimer**: nunca implementé inotify, por lo que este post puede ser incompleto, incorrecto, o cualquier otro “in” que se te ocurra. Su espíritu es simplemente poder referenciar acá cada vez que surja un inconveniente con la herramienta, para no repetir lo que escribo siempre, y para cada vez dar una mejor respuesta. Todo aporte será más que bienvenido.

El mundo real apesta. Existe el hambre, la capa de ozono se debilita, y el software obra de maneras misteriosas.

inotify es una API de Linux que nos permite monitorear cambios en un archivo o directorio. En criollo, es un duende al que le pedimos que levante la mano cuando ocurre algún evento que a nosotros nos interese, como la creación de un archivo en un directorio, la eliminación de un archivo o una escritura.

“Che, me acabás de decir que el 0 sigue existiendo por más que lo pise con otro valor. ¿El 0 es un objeto al que la VM le mantiene referencias y por eso no se lo lleva el Garbage Collector?”

Bien. Escribimos, compilamos y corrimos nuestro primer programa. Pero es como bastante aburrido, ¿no? Vamos a ponerle onda: declaremos una variable (¡iupi! (¿?))

1
2
3
4

int main(void) {
  int exit_status = 0;
  return exit_status;
}

Guau. Me la jugué :) Anoche no dormí porque me quedé debuggeando un error en este programa.

Vamos a hacer un programa en C, por lo que empezamos con una función:

1
2
3

int main (void) {
  return 0;
}

Este es (aproximadamente) el programa más chico que podamos hacer en C. main() es la función que se ejecuta al ejecutar un programa C. En este caso, el prototipo de la función es int main(void): nuestro programa no recibirá parámetros (void), y devolverá a quién lo ejecute un entero signado (int).