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 just saw vim hint 1354 pop up in my RSS feed. It’s a neat idea… but it’s hard to decide what documentation should be looked up. Simply using the file type is insufficient.

It turns out that it’s a lot more awesome to do google codesearch lookup on it.

I love tags files for in coding, and enjoy using the tag feature in [vim]{tag/vim} as well as the derived tag-based completion. I do a lot of my development in the kernel, so all I usually have to do is put /usr/src/linux into my vim tags configuration.

Sometimes I have to do some user space hacking too, and I often forget all the names of glib and pthread library functions. Having a system wide tags file is very very useful. Below is a Makefile that I carry around with me and place in /usr/include to keep my system tags in sync.

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:

I was installing openswan on my [sbc]{tag/sbc} router box. The sbc doesn’t have much hardware on it, and what it does have did not contribute to the entropy pool.

I have a few boxes around with relatively good entropy (keyboard/mouse input), but there was no way to pass that entropy to the router for RSA key generation. I had to write some code to fix it. Be warned, it’s pretty EVIL…

UPDATE: see below about rng-tools.