I’m worried about Sharon. I wish she would find a roommate already. Good luck.
I’ve been invited to do more OpenCVS/OpenRCS development. By “invited” I mean they invited me to join their SILC channel and they sent me their OpenRCS todo list. Unfortunately niallo either forgot to attach the list or everything’s done and he just sent me the empty list. I’m guessing the former and am waiting for him to get back to me about that.
All this OpenBSD development has halted my work on my Systrace talk. Although I’m quite confident when it comes to most things Systrace, I really should prepare so I don’t look like a fool at NYCBUG and risk losing that speck of respect I’ve worked so hard for.
Continuing to find bugs here and there, some obviously need to be committed quickly, others might go in after 3.9, since the tree lock is coming.
I’ve always wanted to play with OpenCVS, but its reliability worried me. Since it worked with the CVS repository I didn’t want it to trash all my revisions accidentally. I didn’t mind losing my current work, but to lose the entire history would be unacceptable. Since I’ve been working with OpenBSD’s stuff recently I can now play with OpenCVS with more ease. It’s not like I have an account on the anoncvs servers, so the most I’ll do is wreck that small diff that I was just working on.
Playing with it has shown that there are still a lot of rough edges. It doesn’t ignore changed $OpenBSD$ tags, for instance, and it also thinks that any file that has a different mtime from the one stored in CVS is modified. I’ve been working on doing what I think GNU CVS does, which is to do a file comparison in addition to checking the mtime. If I work on it for another day or two it should be done.
I’ve been wanting to automate this log for some time now, but I didn’t want to do it in php, which would have been easier. I also wanted to use John Gruber’s MarkDown. I’ve been thinking of doing a reimplementation in C, libmarkdown, so it can be linked in to other CGIs or just executed and parse stdin. My motivation to do this will not come until I at least get this log automated.
I need more time. I need to prepare for the Systrace talk that I’m giving on March 1st, I need to finish up other miscelleneous things I’ve been putting off. So much for being master of time.
I’ve been doing a lot of OpenBSD development recently. (Bug hunting is more like it.) Because of my “1337” skills I was invited to join the OpenBSD community somewhat. While I wasn’t invited to become a fully fledged committer, I’m now hanging out in a channel with many active developers. It’s interesting, seeing the people I’ve always read about from a distance talking amongst themselves in real time.
So recently I’ve been working out all those little things that nagged me about sdiff, such as the -I flag not working if the ignored diffs included line changes and the fact that sdiff didn’t work well with stdin. The -I flag bug was there because of the way I originally implemented sdiff, reading only the first file and the diff for all sdiff output. At the time I figured, the less files and pipes I had open, the less resources I had to use and the more efficient it would be. This proved to be a problem when with the -I flag, because sdiff parses line numbers from the diff output, and the -I flag can mess up the line numbers by ignoring diffs consisting of line additions or deletions. Especially for line additions, since by not reading file2, sdiff wouldn’t even know what to print out.
The fix, naturally, was to read both file1 and file2. Then instead of assuming that after doing a diff the line numbers will always be aligned and continue reading file1 and file2 until the line numbers are synched up.
The stdin bug had eluded me for a while. At first I thought that fparseln doesn’t work with stdin, but writing a simple program dispelled that theory pretty quickly. Since I suck at gdb, I used this opportunity to learn to use it. Looking through the backtrace and figuring out where it stopped and why, I finally realized that when I pass stdin to sdiff, it also gets passed to diff. Correct operation would require both sdiff and diff to read the file and have the same output. Since stdin is a one-time thing, the two processes essentially fought over the stream and both lost. The fix I implemented was to copy all inputs to temporary files and pass them to diff and sdiff to use. If file1 and file2 are the same name only one temporary file is used. I don’t like this because it requires $TMPDIR to contain enough space to hold both file1 and file2, but I don’t see a simpler solution. Additionally simply the two filenames may not mean that they are not the same file. I haven’t tested out what would happen if I tried to do “echo a|sdiff – /dev/stdin”, but I don’t think it will be pretty. I also wonder if open(“/dev/stdin”) == STDIN_FILENO; if so, that would be handy and I could compare those as well.
While looking for examples of correct fgetln, ferror, and feof usage, I stumbled upon some bad code in /usr/src/usr.bin/cap_mkdb. I’ve discovered that there was a lot of code in there that has overflows, NULL dereferences, and other autrocities. Fixing them first required me understanding the input formats. I think I’ve pretty much figured the file formats out. One odd thing was, all the comments had the function names spelled incorrectly. I had a nagging feeling the code was copied and pasted from somewhere, but a cursory search revealed nothing.
So I created some junk inputs that caused segfaults, created regression tests out of them, and submitted fixes via sendbug. Continuing to create more junk inputs and using gdb to trace the source revealed the source of the copy and pasted code, somewhere in libc! Looking into it, I realized that almost every bug in cap_mkdb was copied from the libc code. Ugh, now fixing it will be twice the work.
The more I learn, the more problems I find. I guess this is good, finding things to fix, improving the overall quality of the system. I can see how there’s always room for improvement and areas to fix, though. I can see how the goal of creating robust, bug-free code will be a very long one as well. And I’m just doing housekeeping in dusty code nobody cares about. I hope that this is not all that I wind up doing, though, cleaning up crappy code in obscure areas. I do want to do development.