As I move around, I roam between wifi networks, but sometimes lose the connection. Then I click a link and watch in vain as it fails to load. So I’d like an easy way to check which, if any, wifi network I’m connected to, such as by putting it in my dwm status bar. I could run ifconfig and parse the output, but that’s excessively wasteful. I need to get the info myself.

more...

The OpenBSD kernel is getting to be really old, like really, really old, mid 40s old, and consequently it doesn’t like surprises, so programs have to tell it where their syscalls are. In today’s edition of the polite programmer, we’ll learn the proper etiquette for doing so.

more...

On OpenBSD, there is a rule that you link with libc to interface with the kernel, because that’s where the syscall stubs live. This causes a great deal of consternation for partisans of other languages, because they don’t want to link “all of libc”. But when does anything link all of libc?

more...

What if we want a grep that doesn’t stuck but we don’t want to resort to wild hacks like editing the source? What if there was some way to flush stdout automatically?

The auto flusher is a very simple preload.

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>

static void *
flusher(void *arg)
{
        while (1) {
                sleep(3);
                fflush(stdout);
        }
}

__attribute__((constructor))
void
herewego(void)
{
        pthread_t thread;

        pthread_create(&thread, NULL, flusher, NULL);
}

Magic constructor attribute for initializers in C, and then we create a thread which loops around occasionally flushing stdout, so if there’s any data left lingering, it will eventually find it’s way out instead of waiting forever.

$ cc -shared -lpthread -o libflusher.so flusher.c
$ env LD_PRELOAD=./libflusher.so grep ...

Sometimes pipes get stuck. To recap, if we run this command...

~/src/usr.bin/grep> tail -200 util.c | grep unsigned | grep int
grep_revstr(unsigned char *str, int len)

... we get the expected output. If we run it this way, however, there’s no output.

~/src/usr.bin/grep> tail -f -200 util.c | grep unsigned | grep int

The file isn’t being appended, meaning tail won’t exit, so we don’t expect the pipeline to ever finish, but we would like to see the current results.

Fortunately, grep provides an lbflag we can set. In this case, if the input is a pipe, we’ll assume there’s something fancy going on, and switch to line buffering.

        struct stat sb;
        fstat(0, &sb);
        if ((sb.st_mode & S_IFMT) == S_IFIFO)
                lbflag = 1;

Easy fix. (Or one can read the manual.)

But this is excessive. What about those times when we want the efficiency of buffering? There are lots of possible pipelines that don’t involve tail. What we can do instead is take a peek at some of our neighbors and see what’s really going on. Not perfectly accurate, but probably good enough.

static void
checklbflag()
{
        pid_t pgrp = getpgrp();
        struct kinfo_proc ki[24];
        size_t len = sizeof(ki);
        int mib[6] = { CTL_KERN, KERN_PROC, KERN_PROC_PGRP, pgrp,
                sizeof(ki[0]), sizeof(ki)/sizeof(ki[0]) };

        sysctl(mib, 6, ki, &len, NULL, 0);
        for (size_t i = 0; i < len / sizeof(ki[0]); i++)
                if (strcmp(ki[i].p_comm, "tail") == 0)
                        lbflag = 1;
}

Alas, this requires including <sys/sysctl.h> which will slow down our compiles.

It is also possible, using forbidden magic, to determine whether the pipe we are reading from is being written to by tail, as opposed to a tail at the end of the pipeline, but that’s left as an exercise for the reader.

As noted, Valve uses the same flicker effect for broken lights in all their games. What if I want a broken web page?

more...

For some of the software I write, I try to make occasional releases, and for the go software I vendor the dependencies so it’s all there. I was just reminded that I hadn’t made a release of something in five years, so I reran my release script, and ended up with a tarball that was 10x bigger than the previous one. Some terrible choices have been made.

 317140 May  6  2019 humungus-0.9.6.tgz
3094567 Apr 30 22:25 humungus-0.9.7.tgz

There’s been five years of development, but that’s really not that much. I most certainly have not 10xed the functionality. Where did this all come from?

I poked around the vendor directory for a bit for some large files. One of them is hsluv-snapshot-rev4.json, a 1.5MB json file. I wouldn’t recommend clicking on that link, unless your browser likes displaying single lines of text 1.5MB bytes long.

I have no idea what this file does. The only color I need is for a little green menu in the terminal admin interface. I checked, and go-colorful was a dependency in previous releases, but it didn’t have this file at the time. Apparently I still don’t need it. I just deleted it after running go vendor and everything still works. That reduced the size of the final release tarball by 500K.

2MB (post compression) still to go, or thereabouts. I was in a hurry, so I didn’t actually trim anything more down. The majority of the code is the golang/sys/unix repository. I still have to find out what’s dragging this in, and then delete or rewrite it.

Ah, there it is. tcell nonblock_bsd.go imports sys/unix. 9.5MB of vendored source code to set a flag on a file descriptor.

I have tried to be mindful of the number of dependencies I’m adding. I keep an eye on go.mod to make sure it doesn’t explode. But I’ve been lax in running du on the vendor directory. Even limited sets of dependencies are subject to extreme bloat.

Memory leaks have plagued C programs for as long as the language has existed. Many solutions have been proposed, even going so far as to suggest we should rewrite C programs in other languages. But there’s a better way.

Presented here is a simple solution that will eliminate the memory leaks from every C program. Link this into your program, and memory leaks are a thing of the past.

#include <dlfcn.h>
#include <stdio.h>

struct leaksaver {
        struct leaksaver *next;
        void *pointer;
} *bigbucket;

void *
malloc(size_t len)
{
        static void *(*nextmalloc)(size_t);
        nextmalloc = dlsym(RTLD_NEXT, "malloc");
        void *ptr = nextmalloc(len);
        if (ptr) {
                struct leaksaver *saver = nextmalloc(sizeof(*saver));
                saver->pointer = ptr;
                saver->next = bigbucket;
                bigbucket = saver;
        }
        return ptr;
}

It is now entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.

Problem sovled!

What’s next after you write your own text editor and mail client? How about a terminal? In fact, as a practice exercise or to learn some new skills, I’d say a terminal emulator makes for a much better target. It’s composed of many parts, but at an approachable level, making it easy to make tangible progress. In this way, I think it makes for a good introductory project. At the same time, there’s a very long tail of features that can be added to keep things interesting.

more...

There’s an amazing and famous scene of two hackers sharing a keyboard on NCIS, but it gets a lot of derision on the internet. What people don’t realize is that their mockery only reveals their own lack of skill. As everyone knows, a true hacker has mastered the art of dual wielding, and a keyboard that can be dual wielded by one might also be used by two hackers in tandem.

more...