4 bits blog

Para los que programen en C con Visual Studio y sientan añoranza de valgrind, aquí están los pasos sobre cómo detectar fugas de memoria (memory leaks) en Visual Studio:

• Añadir la macro _CRTDBG_MAP_ALLOC del preprocesador, ya sea definiéndola en algún archivo del proyecto o en las opciones de compilación del proyecto.
• Incluir en el siguiente orden stdlib.h y crtdbg.h en los archivos dónde se busquen las fugas de memoria. El archivo crtdgb.h sustituye las funciones malloc y free por unas propias que registran la memoria reservada y liberada.
• Añadir la función _CrtDumpMemoryLeaks () al final del programa en el que se buscan las fugas de memoria. Esta función muestra por la salida de depuración las fugas de memoria detectadas.

Todo esto sólo funcionará cuando el proyecto se compile con la macro _DEBUG definida, es decir, en lo que debería ser para todos la versión de depuración del programa.

La macro _CRTDBG_MAP_ALLOC sirve para que la función _CrtDumpMemoryLeaks () muestre información sobre el archivo y la línea en la que se produjo la fuga de memoria.

Un pequeño ejemplo de cómo quedaría todo:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

int
main (int argc, char *argv[])
{
    /* Código del programa */

    _CrtDumpMemoryLeaks ();

    return 0;
}

Si este programa tuviera alguna fuga de memoria, al compilarlo en modo depuración y ejecutar el depurador de Visual Studio, se obtendría en la salida de éste un listado con las fugas de memoria del programa.

Para más información, leed el artículo Enabling Memory Leak Detection de la MSDN.

Hace ya bastante tiempo en el trabajo me tocó lidiar con un programa (en C) que debía procesar la configuración de un archivo INI, para quién no lo sepa es un archivo de texto con un formato similar a este:

;Archivo INI

[sección]
clave1=valor1
clave2=valor2

En estos casos lo mejor es no reinventar la rueda, así que hice un par de búsquedas por internet, pero lo que encontré no me gustó, así que ni corto ni perezoso realicé mi propio cutre-parser que funcionaba bien para lo que quería, archivos INI creados a mano, pero no para todos los casos que podría tener un archivo INI.

Así que gracias a un poco de tiempo libre me he puesto las pilas un poco y he ido modificando aquel cutre-parser hasta algo más decente, aunque todavía le quiero dar un par de vueltas para dejarlo bien. De todos modos, el código que hay ahora mismo funciona bastante bien, así que he creado un repositorio para mini en github (por cierto, git mola mil), así no tenéis excusa para probarlo.

Si alguien sabe lo que son las autotools, seguramente haya sufrido para saber cómo funcionan. Hacía mucho tiempo que no me peleaba con ellas, hasta que hace unos días leí un pequeño manual sobre cómo configurar los diferentes archivos necesarios y me acordé de un pequeño manual que hice cuando me tocó pegarme con ellas, que voy a recuperar.

¿Qué son las autotools?

Las autotools, son programas que se usan para crear un paquete de código fuente que se pueda distribuir y compilar de una manera sencilla (configure, make y make install). Los programas que forman las autotools son los siguientes:

• aclocal
• autoconf
• automake

Estos programas son la base para crear el paquete de código fuente, para ello se tendrán que generar unos archivos concretos.

Estructura del código fuente a distribuir

Las autotools se usan para generar el paquete «tar.gz» que contiene el código fuente del programa que se va a distribuir, normalmente estos paquetes siguen una estructura estándar. La estructura básica es:

• src: Directorio del código fuente.
• AUTHORS: Indica los autores del programa.
• ChangeLog: Indica los cambios que se han ido produciendo.
• COPYING: Indica la licencia de distribución que tiene el programa. (Autogenerado)
• INSTALL: Explica cómo instalar el programa. (Autogenerado)
• NEWS: Indica las noticias relacionadas con el programa.
• README: Un pequeño documento en el que se describe el programa y se explican temas concretos de éste.
• THANKS: Indica los agradecimientos que tenga el autor/es.
• TODO: Indica una pequeña lista de cosas por hacer.

De este modo, si se van a utilizar las autotools sería aconsejable seguir la estructura anterior, y crear todos los archivos menos los como «autogenerado» que, obviamente, se generarán automáticamente, aunque siempre se pueden crear a mano ya que puede que no se quiera tener el contenido autogenerado.

Leer el resto »

Windows System Programming es un libro de introducción a la programación sobre Windows (Win32, aunque hay una breve introducción a Win64), con el lenguaje C.

He de decir que este libro no me ha sorprendido mucho, ya que en cuanto llevas algo de tiempo programando sobre Win32 y visitando la MSDN a menudo, te acabas conociendo las partes más utilizadas. Además, este libro es bastante antiguo (del 2004).

En general, no me convence la forma de explicar los temas por parte del autor, casi todos los capítulos se limita a copiar las diferentes funciones que se utilizan para hacer lo que sea, y a explicar cada uno de sus parámetros. Por lo que el libro se transforma en una especie de resumen de la MSDN.

De todo el contenido del libro me quedaría con los capítulos sobre los servicios de Windows y las estructuras de seguridad (SIDs, ACLs, ACEs) de Windows.

Aún así, puede servir como punto de partida para empezar a programar sobre Windows utilizando Win32, si no fuera por las pegas que he comentado.

Recomendación: Baja.
Nivel: Medio.
Idioma: Inglés.

En Windows existen cinco señales de la consola que se emiten cuando se producen varios eventos, todos relacionados con el fin de la aplicación (Ctrl+C o Ctrl+Break), con el cierre de la consola (más llanamente, es el cierre de la ventana del cmd.exe) o con el fin de la sesión en Windows (el cierre de una sesión de usuario o el apagado del sistema).

Windows emite estas señales a las aplicaciones correspondientes para que puedan manejarlas y terminar de una forma adecuada, por ejemplo: realizando las operaciones necesarias para no dejar archivos en algún estado catastrófico perdiendo la información de estos.

Manejando las señales

Para manejar estas señales las aplicaciones disponen de una lista de manejadores, en la que en principio sólo hay una función que termina la ejecución del proceso. Para añadir/borrar un manejador a la lista se dispone de la función SetConsoleCtrlHandler:

BOOL WINAPI SetConsoleCtrlHandler (PHANDLER_ROUTINE HandlerRoutine, BOOL Add);

Donde los parámetros son:

• HandlerRoutine: Es un puntero a la función que manejará las señales recibidas. Tendrá la forma:

  BOOL WINAPI CtrlHandler (DWORD CtrlType)

• Add: Si su valor es TRUE indica que la función se añadirá a la lista de manejadores de las señales, en cambio si es FALSE indica que la función se borrará de la lista de manejadores.

Leer el resto »