El bueno, el feo y el VLA cómo usar los Variable Length Arrays en C - pt.1

La referencia cinematográficas de este mes es ideal: un Variable Length Array (VLA para los amigos) sería perfecto para interpretar el malo en la obra maestra "El bueno, el feo y el malo" del legendario Sergio Leone. Y al final del(proximo) post resultará claro por qué.

...hola soy un VLA: comienza a preocuparte...

Los VLAs son una cosa relativamente nueva del C: se introdujeron en C99, y son, al parecer, el sueño hecho realidad del mundo C: "¡Finalmente hay array con dimensiones variable! ¡Ah, si los hubiera tenido antes '99!". Vale, la idea es simple: con un VLA tipo podéis escribir cositas como estas:

void myVla(
    int size1,
    int size2)
{
    // mi VLA de int
    int ivla[size1];

    // hace algo con el VLA de int
    ...

    // mi VLA bidimensional de float
    float fvla[size1][size2]:

    // hace algo con el VLA bidimensional de float
    ...
}

¿Fantastico, no? Demasiado bueno para ser verdad... pero habrá algunas contraindicaciones? Definitivamente no en el rendimiento: justo por eso he escrito un poco de código para poner a prueba las prestaciones de los VLAs respeto a las alternativas directas: array dinámicos (con malloc()) y array estáticos (en heap y stack). ¡vamos con el código!

#include <stdio.h>
#include <time.h>
#include <stdlib.h>

#define MYSIZE  1000000

// variable dummy con el fin de evitar el vaciado total de las funciones usando GCC -O2
int avoid_optimization;

// prototipos locales
void testVLA(int size);
void testMallocVLA(int size);
void testStackFLA(int dum);
void testHeapFLA(int dum);
void runTest(int iterations, void (*funcptr)(int), int size, const char *name);

// función main()
int main(int argc, char* argv[])
{
    // test argumentos
    if (argc != 2) {
        // error args
        printf("%s: wrong arguments counts\n", argv[0]);
        printf("usage: %s vla iterations [e.g.: %s 10000]\n", argv[0], argv[0]);
        return EXIT_FAILURE;
    }

    // extrae iteraciones
    int iterations = atoi(argv[1]);

    // ejecuta test
    runTest(iterations, &testVLA, MYSIZE, "testVLA");
    runTest(iterations, &testMallocVLA, MYSIZE, "testMallocVLA");
    runTest(iterations, &testStackFLA, 0, "testStackFLA");
    runTest(iterations, &testHeapFLA, 0, "testHeapFLA");

    // sale
    return EXIT_SUCCESS;
}

// función runTest()
void runTest(
    int        iterations,      // iteraciones del test
    void       (*funcptr)(int), // función de test
    int        size,            // size del array
    const char *name)           // nombre función de test
{
    // lee start time
    clock_t t_start = clock();

    // ejecuta iteraciones de test
    for (int i = 0; i < iterations; i++)
        (*funcptr)(size);

    // lee end time y enseña el resultado
    clock_t t_end = clock();
    double t_passed = ((double)(t_end - t_start)) / CLOCKS_PER_SEC;
    printf("%-13s -  Tiempo transcurrido: %f segundos\n", name, t_passed);
}

// función testVLA()
void testVLA(
    int size)       // size para VLA
{
    int vla[size];

    // loop de test
    for (int i = 0; i < size; i++)
        vla[i] = i;

    // instrucción con el fin de evitar el vaciado total de las funciones usando GCC -O2
    avoid_optimization = vla[size / 2];
}

// función testMallocVLA()
void testMallocVLA(
    int size)       // size para malloc()
{
    int *mallocvla = malloc(size * sizeof(int));

    // loop de test
    for (int i = 0; i < size; i++)
        mallocvla[i] = i;

    // instrucción con el fin de evitar el vaciado total de las funciones usando GCC -O2
    avoid_optimization = mallocvla[size / 2];

    free(mallocvla);
}

 
// función testStackFLA()
void testStackFLA(
    int dum)        // parámetro dummy
{
    int stackfla[MYSIZE];

    // loop de test
    for (int i = 0; i < MYSIZE; i++)
        stackfla[i] = i;

    // instrucción con el fin de evitar el vaciado total de las funciones usando GCC -O2
    avoid_optimization = stackfla[size / 2];
}

// función testHeapFLA()
int heapfla[MYSIZE];
void testHeapFLA(
    int dum)        // parámetro dummy
{
    // loop de test
    for (int i = 0; i < MYSIZE; i++)
        heapfla[i] = i;
}

Aquí, como siempre, corto-y-pego lo que siempre escribo después de mostrar el código (equipo que gana no se cambia...): Ok, como se nota es ampliamente comentado y así se auto-explica, por lo cual no voy a detenerme sobre las instrucciones y/o grupos de instrucciones (¡leer los comentarios! ¡Están ahí para eso!), pero voy a añadir, solamente, algunos detalles estructurales.

Así que: dado que es un test comparativo he escrito una función runTest() que llama n-iteraciones de la función a probar y cuenta el tiempo utilizado. el main() llama simplemente cuatro veces runTest(), una para cada función. Las cuatro funciones de test que he escrito prueban (como indicado por los nombres, por supuesto): un C99-VLA, un tradicional malloc-VLA, un Fixed-LA alocado en el stack, y un Fixed-LA alocado en el heap. Para cada test se utiliza un (gran) array-size de 1000000, y el número de iteraciones se decide arrancando la aplicación (esto es muy útil, como veremos más adelante).

Hay que notar que runTest() utiliza un function pointer para arranar el test (hemos visto algo parecido hablando aquí de las callback): he utilizado la versión extendida de la declaración (void (*funcptr)(int) + llamada de la función con el operador &) pero os recuerdo que, por ejemplo, GCC también digiere fácilmente la declaración simplificada (void funcptr(int) + llamada sin el operador &). La versión extendida es, obviamente, más portátil. Y ya que estamos en el tema de los compiladores: aunque los VLAs (y los loop for (int...)) que utilizo el código de este mes se permiten sólo de C99 en adelante no es necesario (si se utiliza GCC) especificar el flag -std=c99 en compilación: las versiones recientes de GCC incluyen por defecto (al menos) también el C99 (además de las extensiones GNU C): si realmente queréis estar seguros de que lo que habéis escrito cumpla con un standard en particular tenéis que utilizar otros flag: por ejemplo, si queréis escribir utilizando sólo el C89, tenéis que añadir en la línea de compilación: -std=c89 -pedantic. Si estáis utilizando un GCC un poco viejo la compilación del ejemplo os dará warning y/o errores, y habrá que volver a compilar forzando la compatibilidad con el C99.

Los resultados son los siguientes:

aldo@ao-linux-nb:~/blogtest$ gcc vla.c -o vla
aldo@ao-linux-nb:~/blogtest$ ./vla 1000
testVLA       -  Tiempo transcurrido: 4.263985 segundos
testMallocVLA -  Tiempo transcurrido: 3.641929 segundos
testStackFLA  -  Tiempo transcurrido: 4.292963 segundos
testHeapFLA   -  Tiempo transcurrido: 4.285660 segundos
aldo@ao-linux-nb:~/blogtest$ gcc -O2 vla.c -o vla
aldo@ao-linux-nb:~/blogtest$ ./vla 10000
testVLA       -  Tiempo transcurrido: 0.767087 segundos
testMallocVLA -  Tiempo transcurrido: 0.690925 segundos
testStackFLA  -  Tiempo transcurrido: 0.678178 segundos
testHeapFLA   -  Tiempo transcurrido: 0.687785 segundos

Como se puede ver he ejecutado dos test con/sin optimización (flag GCC -O2) y, obviamente, ha sido muy útil el parámetro n-iteraciones de la aplicación, que me ha permitido encontrar un valor adapto para obtener resultados significativos y, al mismo tiempo, para evitar tiempos de ejecución bíblicos con la versión sin optimizaciones. ¿Cómo podemos comentar? Pues bien, ¡el VLA se porta muy bien con/sin optimizaciones! Y consigue, prácticamente, los mismos resultados de su competidor directo, el malloc-VLA, ¡y es más fácil de usar!

Así que, volviendo al tema principal: ¡VLA aprobado!

PERO...

bueno, el porque del VLA malo os lo explicaré en el próximo post, y que sepáis que no todo lo que brilla es oro... y solo por hacer un pequeño spoiler sobre las consideraciones finales: ¡yo nunca utilizo los VLAs en el código que escribo!

¡Hasta el próximo post!

The FileCopy cómo escribir una función de File Copy en C - pt.2

Ok, re-empezamos de donde nos dejamos en el último post (¿lo habeis leido verdad?) Y, como prometido, en esta ocasión el tema será una versión con buffered I/O de la función cpFile(). Es deber, antes, proporcionar otra imagen de The Thing, si no, de lo contrario, podría parecer que esto es sólo un blog de programación, mientras que, como bien sabéis, es un blog para programadores cinefilos...

...con un sombrero así se programa mejor...

Vale, repetimos: I/O buferizado (y por lo tanto, por ejemplo, fread(3) en lugar de read(2), porque el objetivo esta vez es la portabilidad ¿y que hay más portátil (en C) que usar el contenido de stdio.h? El código que veremos en un momento utiliza (casi) el mismo main() de la versión unbuffered y los únicos cambios son internos a la función cpFile(). De hecho, incluso la cpFile() es casi idéntica desde un punto de vista lógico, ya que las funciones buffered tienen una sintaxis de uso y un funcionamiento muy similar a las equivalentes versiones unbuffered. Y claro, si la versión buffered os sale muy diferente (visualmente y lógicamente) de la versión unbuffered es que hay algo que no funciona... bueno, sobre este punto voy a hacer un pequeña digresión al final del post. Por ahora: ¡vamos con el código!

#include <stdio.h>
#include <stdlib.h>

// prototipos locales
static int cpFile(const char* src, const char* dest);

// función main()
int main(int argc, char *argv[])
{
    // test argumentos
    if (argc != 3) {
        // error args
        printf("%s: wrong arguments counts\n", argv[0]);
        printf("usage: %s srcfile destfile [e.g.: %s try.c try.save]\n", argv[0], argv[0]);
        return EXIT_FAILURE;
    }

    // ejecuta copia
    int retval;
    if ((retval = cpFile(argv[2], argv[1])) < 0) {
        // enseña error y sale con error
        fprintf(stderr, "%s: error: %d\n", argv[0], retval);
        exit(EXIT_FAILURE);
    }

    // sale con Ok
    return EXIT_SUCCESS;
}

// función cpFile()
static int cpFile(
    const char *dest,               // file destinación
    const char *src)                // file fuente
{
    // abre el file fuente
    FILE *fp_in;
    if ((fp_in = fopen(src, "r")) == NULL) {
        // return con error
        return -1;
    }

    // abre el file destinación
    FILE *fp_out;
    if ((fp_out = fopen(dest, "w")) == NULL) {
        // cierra el file y return con error
        fclose(fp_in);
        return -2;
    }

    // r/w loop para la copia usando buffered I/O
    size_t n_read;
    char buffer[BUFSIZ];
    while ((n_read = fread(buffer, 1, sizeof(buffer), fp_in)) > 0) {
        if (! ferror(fp_in)) {
            // write buffer
            fwrite(buffer, 1, n_read, fp_out);
            if (ferror(fp_out)) {
                // cierra los file y return con error
                fclose(fp_in);
                fclose(fp_out);
                return -3;
            }
        }
        else {
            // cierra los file y return con error
            fclose(fp_in);
            fclose(fp_out);
            return -4;
        }
    }

    // cierra los file
    fclose(fp_in);
    fclose(fp_out);

    // return con Ok
    return 0;
}

Ok, como se nota es ampliamente comentado y así se auto-explica, por lo cual no voy a detenerme sobre las instrucciones y/o grupos de instrucciones (¡leer los comentarios! ¡Están ahí para eso!), pero voy a añadir, solamente, algunos detalles estructurales. El main(), como se había anticipado, es prácticamente idéntico, mientras que en la cpFile() se repiten, exactamente, las operaciones de la version unbuffered, pero usando fopen(3) en lugar de  open(2), fclose(3) en lugar de close(2), etc. ¿Donde encontramos algunas (pequeñas) diferencias? Sólo en el test de (eventuales) errores de lectura/escritura, que en la versión unbuffered estaban implícitas en las operaciones de read/write (probando si el resultado era igual a -1), mientras que en este caso hay que usar una función a parte, ferror(3), y esto es debido a que:

    On  success,  fread()  and  fwrite() return the number of items read or
    written.  This number equals the number of bytes transferred only  when
    size  is 1.  If an error occurs, or the end of the file is reached, the
    return value is a short item count (or zero).
    fread() does not distinguish between end-of-file and error, and callers
    must use feof(3) and ferror(3) to determine which occurred.

Lo anterior es lo que trae la man-page de fread(3)/fwrite(3), y creo que es una justificación suficiente de por qué he escrito el código asì (y, por lo mismo, no podemos usar strerror(3) en el main() para enseñar los errores). Así que, como se había anticipado, las versiones buffered y unbuffered deben ser casi sobreponibles, y creo que es exactamente el resultado conseguido.

Y ahora la digresión prometida: me ha pasado de encontrar en la red (incluso en apreciados blogs/webs de programación) ejemplos de buffered-copy de file que utilizan unos loop de este tipo:

while (!feof(fp_in)) {
    // lee y escribe buffer
    ...
}

vale, ¿cómo se puede comentar esto? Con una sola palabra:

NO

Si uno escribe el loop de esta manera significa que no ha leído la man-page de fread(3)/fwrite(3) o que la ha leido y no ha entendido el contenido. No hay necesidad de reinventar la rueda, repito: fread(3)/fwrite(3) funcionan casi de la misma manera de read(2)/write(2), por lo que, si el ejemplo de cpFile() unbuffered del post anterior era bueno (¡y lo era!), entonces el ejemplo del post actual debería ser (casi) idéntico. El loop con un while() que testea feof(3) es sintácticamente correcto, pero no lo es lógicamente, ya que comienza testeando algo que todavía no es utilizable (uhmm, ¿una prueba predictiva?) y que, además, no hay necesidad de testear. Bah, no quiero extender demasiado este argumento y os remito a la excelente análisis contenida ahí (en el siempre optimo stackoverflow.com).
Obviamente espero no haber ofendido a nadie (con la digresión anterior): Recordar que errare humanum est... y, por supuesto, también en este blog habré escrito en el pasado algunas tonterías (espero no graves como aquella enseñada hace un momento). Os aseguro, sin embargo, que yo siempre soy muy cuidadoso de no proponer soluciones que no he tenido tiempo para escribir y probar de manera curada, o de lo contrario en lugar de un blog de programación artística este sería un blog de programación a la esperamos que funciona...

¡Hasta el próximo post!

The FileCopy cómo escribir una función de File Copy en C - pt.1

Ok, este post no tiene nada que ver con The Thing, la inmortal obra maestra de John Carpenter (aparte de la pequeña similitud del nombre). De hecho, es sólo una excusa para celebrarlo, ya que lo he visto (por milésima vez) recientemente. Sin embargo, ya que estamos, hablaremos también un poco de C...

inmortal obra maestra

Con este post veremos cómo escribir una función para realizar una copia de un file, ya que los sistemas POSIX (como Linux) no proporcionan una función específica de librería para hacerlo. Hay, por supuesto, mil formas de escribirla, y esta vez he pensado en dos versiones. ¡Vamos con la primera!

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/sendfile.h>

// prototipos locales
static int cpFile(const char* src, const char* dest);

// función main()
int main(int argc, char *argv[])
{
    // test argumentos
    if (argc != 3) {
        // error args
        printf("%s: wrong arguments counts\n", argv[0]);
        printf("usage: %s srcfile destfile [e.g.: %s try.c try.save]\n", argv[0], argv[0]);
        return EXIT_FAILURE;
    }

    // ejecuta copia
    if (cpFile(argv[2], argv[1]) == -1) {
        // enseña error y sale
        fprintf(stderr, "%s: error: %s\n", argv[0], strerror(errno));
        exit(EXIT_FAILURE);
    }

    // sale
    return EXIT_SUCCESS;
}

// función cpFile()
static int cpFile(
    const char *dest,               // file destinación
    const char *src)                // file fuente
{
    // abre el file fuente
    int fd_in;
    if ((fd_in = open(src, O_RDONLY)) == -1) {
        // return con errore
        return -1;
    }

    // abre el file destinación
    int fd_out;
    if ((fd_out = open(dest, O_WRONLY | O_CREAT | O_TRUNC, 00644)) == -1) {
        // cierra el file y return con error
        close(fd_in);
        return -1;
    }

    // r/w loop para la copia usando unbuffered I/O
    size_t n_read;
    char buffer[BUFSIZ];
    while ((n_read = read(fd_in, buffer, sizeof(buffer))) > 0) {
        // write buffer
        if (write(fd_out, buffer, n_read) == -1) {
            // cierra el file y return con error
            close(fd_in);
            close(fd_out);
            return -1;
        }
    }

    // cierra los file
    close(fd_in);
    close(fd_out);

    // sale con el ultimo resultado de read() (0 o -1)
    return n_read;
}

Ok, como se nota es ampliamente comentado y así se auto-explica, por lo cual no voy a detenerme sobre las instrucciones y/o grupos de instrucciones (¡leer los comentarios! ¡Están ahí para eso!), pero voy a añadir, solamente, algunos detalles estructurales. El main(), en este caso, sólo sirve para probar la función de copia y el programa generado se comporta (a nivel básico) como la función POSIX cp(1), que es precisamente lo que queremos emular usando la nuestra nueva función de librería.

La función que hace el trabajo la he llamada cpFile() y es bastante simple, como se ve. Utiliza el I/O sin búfer (así, por ejemplo, read(2) en lugar de fread(3)) y, aunque es muy compacta y eficiente, también trata de forma integral los errores y està escrita para ser una función de librería, por lo que no escribe nada en stderr y stdout sino simplemente realiza el trabajo y devulve un código de retorno (0 ó -1), que puede ser tratado por el llamante (en este caso el main()) para mostrar eventuales errores utilizando strerror(3) y errno. Todo el trabajo se realiza en un loop que lee un buffer en el file fuente y lo escribe en el file de destino, hasta el final del file. El resto del código es la abertura/cierre de los file y manejo de los errores. Teniendo en cuenta que utilizamos el unbuffered I/O he dimensionado el búfer de lectura/escritura utilizando la define BUFSIZ del sistema que deberia garantizar un tamaño óptimo para las operaciones de I/O. 

He dicho que iba a proponer dos versiones: sin modificar la función main() (que está bien para ambos casos) la versión alternativa es la siguiente:

// función cpFile()
static int cpFile(
    const char* dest,               // file destinación
    const char* src)                // file fuente
{
    // abre el file fuente
    int fd_in;
    if ((fd_in = open(src, O_RDONLY)) == -1) {
        // return con errore
        return -1;
    }

    // abre el file destinación
    int fd_out;
    if ((fd_out = open(dest, O_WRONLY | O_CREAT | O_TRUNC, 00644)) == -1) {
        // cierra el file y return con error
        close(fd_in);
        return -1;
    }

    // copia en kernel-space usando la función sendfile()
    off_t bytesCopied = 0;
    struct stat fileinfo = {0};
    fstat(fd_in, &fileinfo);
    int result = sendfile(fd_out, fd_in, &bytesCopied, fileinfo.st_size);

    // cierra los file
    close(fd_in);
    close(fd_out);

    // sale con el resultado de sendfile()
    return result;
}

Como se puede ver, casi se puede sobreponer a la anterior, pero es diferente, precisamente, en la parte que realiza el trabajo de copia: en lugar del loop se utiliza la función sendfile(2), lo que nos permite realizar una copia directa y super-eficiente a nivel de kernel-space (mientras que la primera versión trabajaba en user-space).

Sin entrar en los detalles profundos que todo esto conlleva (kernel-space y user-space de los sistemas de la familia UNIX), me limitaré a señalar que esta segunda versión es mejor que la primera, pero es menos portátil, ya que la sendfile(2) tiene un comportamiento diferente en función del sistema (por ejemplo, sobre Linux se puede utilizar sólo con dal Kernel 2.6.33 hacia adelante, mientras que en macOS, por el contrario, sólo funciona hasta la versión 10.8). Y ya que estamos especificamos mejor: también la primera versión no es totalmente portátil, ya que en algunos sistemas (como el que se inicia con W y que prefiero no nombrar ni siquiera) la system call read(2) no está disponible.

Ok, entonces ya se puede adivinar que el tema del próximo post será una versión con buffered I/O de la función cpFile(), o sea una versión intrínsecamente portátil, ya que utilizará el I/O standard del C (lo que está contenido en stdio.h, para entendernos).

Y, por favor,  no contengáis la respiración esperando...

¡Hasta el próximo post!