This is a follow up to my [pretty function tracing]{pretty-function-tracing} article. I base this work on the code presented there.

Some one asked me how to get the gcc -finstrument-functions feature working. If you don’t know this flag will modify the entry and exit to/from each function to make a call out to a special set of functions used for tracing.

While I’ve read about this feature, I never actually tried it. So here is what I learned…

I was squashing some warnings in [uzbl]{tags/uzbl} code:

    printf("set %s = %d\n", (char *)k, (int)*c->ptr);

Ignoring the fact that, at first glance, it’s weird to cast a pointer to int (ptr is defined as void**), compiling this code on 64bit would warn you that you were casting a pointer to an int. That’s because a pointer is 64bit and an int is 32bit.

I’ve look around for an open source implementation of popen() that can handle redirection of stdin, stdout, and stderr of the program executed. I was unable to find one, so I wrote my own.

If you need to fork a helper process and maintain bidirectional communication wtih it, then you can use my popenRWE() (source: popenRWE.c.

Here is an example of how it might be used:

    int pipe[3];
    int pid;
    const char *const args[] = {
            "cat",
            "-n",
            NULL
    };

    pid = popenRWE(pipe, args[0], args);

    // write to pipe[0] - input to cat
    // read from pipe[1] - output from cat
    // read from pipe[2] - errors from cat

    pcloseRWE(pid, pipe);

Someone on #oclug was asking about building C programs with make. I wrote up this simple Makefile for him.

It would seem that either no one that codes for the Linux kernel does so under vim, or if they do they don’t have the time to share their vim configuration that doesn’t conflict with the kernel’s CodingStyle.

Below I will discuss some changes I had to make to my .vimrc and .vim/c.vim to work with C efficiently.

A new comer to my place of work was asking me how he can improve his code style. Here are some suggestions I had for him.

I wanted to see how different functions got used in a block of code that I was new to… and was having a hard time understanding. My UML instance was acting flaky and didn’t cooperate with gdb, so I could not single step the code.

I added a small chunk of C code to generate pretty tracing that looks like this:

    ,-< ipsec_sa_wipe:946
    | ,-< ipsec_sa_put:549
    | `-> ipsec_sa_put:561 = 0
    `-> ipsec_sa_wipe:1054 = 0

Functions can nest upto 25 times (arbitrary max) and after that it stops indenting nicely. The code has to be modified so that at the entry of each block there is a call to the IN macro, and on the exit to the OUT macro. Here is an example: