how to write a perfect arena allocator with zero issues

Unknown — Sun, 11 Oct 2026 00:00:00 +0000

If you jumped from below. Jump back to where you came from.

tl;dr:

uint8_t*
ak_arena_alloc(AK_Arena *arena, size_t unaligned_size_bytes, size_t align) {
    ak_assert(arena->top_slab == NULL || arena->top_slab != arena->top_recycled_slab);
    ak_assert(arena->top_slab == NULL || arena->top_slab->down != arena->top_slab);

#   ifdef AK_FEATURE_ASAN
    align = align < AK_ASAN_BYTE_GRANULARITY ? AK_ASAN_BYTE_GRANULARITY : align;
#   endif //AK_FEATURE_ASAN


    ////////////////////////////////////////
    // ~~ Plan A: use the current slab ~~

    if (ak_likely(arena->top_slab != NULL)) {
#       ifdef AK_FEATURE_ASAN
            arena->current_offset += AK_ASAN_PADDING_BYTES;
#       endif // AK_FEATURE_ASAN
             
        uintptr_t start_addr = ak_align_up((uintptr_t)arena->top_slab->buf + arena->current_offset, align);
        uintptr_t end_addr = (uintptr_t)arena->top_slab->buf + arena->top_slab->cap;

        if (ak_likely(start_addr + unaligned_size_bytes <= end_addr)) {
            ak_asan_unpoison((uint8_t*)start_addr, unaligned_size_bytes);
            ak_memzero((uint8_t*)start_addr, unaligned_size_bytes);

            arena->current_offset = (uint8_t*)start_addr + unaligned_size_bytes - arena->top_slab->buf;

            return (uint8_t*)start_addr;
        }

#       ifdef AK_FEATURE_ASAN
            arena->current_offset -= AK_ASAN_PADDING_BYTES;
#       endif // AK_FEATURE_ASAN
    }


    //////////////////////////////////////////////////
    // ~~ Plan B: first-fit an existing free slab ~~

    if (ak_alloc_get_flags(arena->host) & AK_AllocatorFlag_NoRecycle) {
        goto plan_c;
    }

    AK_Slab *to_reuse = arena->top_recycled_slab;
    while (to_reuse != NULL) {
        uintptr_t start_addr = ak_align_up(
            (uintptr_t)to_reuse->buf
#           ifdef AK_FEATURE_ASAN
                + AK_ASAN_PADDING_BYTES
#           endif // AK_FEATURE_ASAN
            , align
        );
        uintptr_t end_addr = (uintptr_t)to_reuse->buf + to_reuse->cap;

        if (start_addr + unaligned_size_bytes <= end_addr) {
            if (arena->top_recycled_slab == to_reuse) {
                ak_assert(arena->top_recycled_slab->up == NULL);
                arena->top_recycled_slab = arena->top_recycled_slab->down;
            }
            ak_slab_unlink(to_reuse);

            ak_assert(to_reuse->down == NULL);
            ak_assert(to_reuse->up == NULL);

            if (arena->top_slab != NULL) {
                arena->top_slab->up = to_reuse;
            }
            to_reuse->down = arena->top_slab;
            arena->top_slab = to_reuse;
            arena->current_offset = (uint8_t*)start_addr + unaligned_size_bytes - to_reuse->buf;

            ak_asan_unpoison((uint8_t*)start_addr, unaligned_size_bytes);
            ak_memzero((uint8_t*)start_addr, unaligned_size_bytes);

            return (uint8_t*)start_addr;
        }

        to_reuse = to_reuse->down;
    }


    ////////////////////////////////////////
    // ~~ Plan C: allocate a new slab ~~

plan_c:;

    const size_t default_slab_size = ak_alloc_get_default_pre_allocation(arena->host);
    const size_t buf_size = unaligned_size_bytes + align > default_slab_size ?
        unaligned_size_bytes + align :
        default_slab_size;
    const size_t total_size = sizeof(AK_Slab) + buf_size;

    AK_Slab *next_on_top = (AK_Slab*)ak_alloc_nozero(arena->host, total_size, _Alignof(AK_Slab));
    if (next_on_top == NULL) {
        return NULL;
    }

    ak_assert(ak_align_up((uintptr_t)next_on_top, _Alignof(AK_Slab)) == (uintptr_t)next_on_top);

    ak_memzero(next_on_top, sizeof(AK_Slab));
    next_on_top->cap = buf_size;

    if (arena->top_slab != NULL) {
        arena->top_slab->up = next_on_top;
    }
    next_on_top->down = arena->top_slab;

    ak_asan_poison(next_on_top->buf, next_on_top->cap);

    uintptr_t start_addr = ak_align_up(
        (uintptr_t)next_on_top->buf
#       ifdef AK_FEATURE_ASAN
            + AK_ASAN_PADDING_BYTES
#       endif // AK_FEATURE_ASAN
        , align
    );
              
    ak_asan_unpoison((uint8_t*)start_addr, unaligned_size_bytes);
    ak_memzero((uint8_t*)start_addr, unaligned_size_bytes);

    arena->top_slab = next_on_top;
    arena->current_offset = (uint8_t*)start_addr + unaligned_size_bytes - arena->top_slab->buf;

    return (uint8_t*)start_addr;
}

note: This may not be what the allocator in the repository looks like by the time you read this. If my code is wrong or could be better, email me or submit a PR (it would be greatly appreciated; I would rather the code be right and I be wrong than I be right and the code be wrong).

What's an allocator, anyway? What's an arena?

An allocator (also known as a memory allocator) allocates memory by dividing an existing chunk of bytes into smaller chunks in some way so that those chunks may be used by your program to store state.

An arena allocator is a kind of allocator that functions effectively as a parallel call stack, while being significantly safer for dynamically-sized things, and also decoupled from the control flow of your program.

I would go into more detail, but this article by Ryan Fleury explains what this actually means, and why this is helpful with far more pedagogical clarity than I would be comfortable competing with.

My Arena

Evidently, the main virtue of the arena allocator is that it is not substantially more complicated than assembling department store furniture. So why is mine?

The answer to that lies in the fact that, Akimbo, the thing this allocator was written for, is a library. As such, I have multiple masters to serve, namely the hardware, the end user, and my sanity.

By default, arenas serve two of those masters very well simultaneously.

The Hardware

If your point of reference is a global, process-wide, thread-safe, functionally dilettante nightmare, then arenas are incredibly fast. If your point of reference is

lea rsp, [rsp - rax] ; alloca(/* whatever is in `rax` */);

then they're still not that bad.

The fast path cost of allocating memory from an arena is so negligible that the Amortized Dynamic Allocation Penalty™ shrinks to near-zero.

This is not to mention that things allocated close to each other temporally are also allocated close to each other spatially. Why does that matter?

Because actually reading and writing from the actual stick of silicon you call RAM is incredibly slow, the CPU generally accesses memory through a cache, a piece of memory that is designed specifically to be bottlenecked by anything other than "how fast do those electrons move." The cache stores contiguous chunks of memory called cache lines. A component called the pre-fetcher is capable of observing and predicting memory access patterns to speculatively load cache lines with the hope that they will already be present by the time they're needed.

Because of this, almost every application-grade processor made in the last 25 years will appear to be faster when accessing memory close to whatever it just accessed.

Now, what are stacks, and by extension arena allocators, condemned to do infin a l'etterno?

Access memory close to whatever was just accessed.

My Sanity

They simplify the usage code commensurately with the amount they simplify the hardware's job.

This point is best made by the aforementioned Ryan Fleury piece, but I'll do my best to summarize: instead of considering the lifetimes of individual "things," you group state by "when is the first and last time this will ever need to exist," and let the invariants of the arena do the rest of the work for you.

This is objectively much simpler than the industry default "untangle a pointer jungle" model that tends to induce the existence of memory management mechanisms like garbage collection and RAII.

But, what about the end user?

While the theory of the arena allocator may be one of the most beautiful concepts one encounters on the path to systems engineering priesthood, it ignores the first question you have to answer when you write one: how much memory do I give it?

If this is your runtime and your process under your control, then it is perfectly reasonable to allocate 64 GB of virtual memory, and let demand paging do what it was designed for.

I, however, am writing a library where I do not know very much more about where my code will be running than it is a computer of some kind, probably. As such, I need a means for the caller to inject their own allocation mechanisms.

The Virtual Allocator

note: It's not strictly necessary to understand the minutiae how the virtual allocator works to understand how the arena itself works, but I thought it was interesting enough to write about. Skip this subsection if you don't care.

The specific flavor of Akimbo's virtual allocator is of enough substance to warrant an article on its own, mostly to say that I stole it from Jonothan Blow's Jai programming language, but I will go over it (not so) briefly.

The most common solution to "cyclic behavioral dependencies," i.e, where Part A of the program depends on the output of Part B, which needs something from Part A (other than just passing something in) is a vtable. The term vtable is rather obfuscatory shorthand for "struct of function pointers and a state pointer" -- something like this:

typedef struct
TheVTable {
    void *ctx; // our state ptr
    int (*some_fn)(void *ctx, int some_arg);
    int (*some_other_fn)(void *ctx, int some_other_arg);
} TheVTable;

The issue: remember that pre-fetcher we talked about? It will frequently attempt to dereference things that look like memory addresses ahead of time, so that when the code actually loads the value at that addresses, it's already sitting in the cache. This happens regardless of whether the data behind that address is data in the traditional sense, or machine instructions.

mov rax, qword ptr [some_address] ; the pre-fetcher can fetch this "data in the traditional sense"
jmp some_address ; and these "machine instructions"

However, consider this example:

mov rax, qword ptr [rdi+16]
jmp rax

To execute this jump the CPU has to ...

figure out what rdi + 16 is,
load the memory address behind rdi + 16 (explicitly into rax for clarity),
load the machine code behind the address in rax into the cache,
and set the program counter to the address in rax.

The pre-fetcher cannot help you here. If it does not know where the machine code it needs to load is (because the value is not in a register yet by step 1), it cannot load it. As such, the computer will commit a venial cache miss.

That is approximately what happens when you call a function behind a vtable (I say approximately, because you would actually set the arguments according to the calling convention, and use call rax).

The solution? Swap the layers of indirection. Instead of having the code be behind the table, move the table behind the code:

typedef uint8_t
AK_AllocatorMode;
enum AK_AllocatorMode {
    AK_AllocatorMode_Alloc,
    AK_AllocatorMode_Free,
    AK_AllocatorMode_GetDefaultPreAllocation,
    AK_AllocatorMode_GetFlags,
};

typedef uint32_t 
AK_AllocatorFlags;
enum {
    AK_AllocatorFlag_NoRecycle    = UINT32_C(0x1),
    AK_AllocatorFlag_AssumeZeroed = UINT32_C(0x1) << 1,
};

typedef union
AK_AllocatorParams {
    struct {
        size_t size_bytes;
        size_t align;
    } alloc;    

    struct {
        uint8_t *ptr;
        size_t size;
        size_t align;
    } free;

    // void get_default_pre_allocation
    // void get_flags
} AK_AllocatorParams;

typedef union
AK_AllocatorReturn {
    struct {
        uint8_t *ptr;
    } alloc;

    // void free;

    struct {
        size_t size_bytes;
    } get_default_pre_allocation;

    struct {
        AK_AllocatorFlags flags;
    } get_flags;
} AK_AllocatorReturn;

typedef AK_AllocatorReturn (*
AK_AllocatorFunction)(void *ctx, AK_AllocatorMode mode, AK_AllocatorParams params);

/// To be passed by value, since it is not all that large, and doing so
/// eliminates dependent instruction loads.
///
/// Don't try to get clever and swap this out under the library's feet between calls.
/// That will almost certainly end poorly.
typedef struct
AK_Allocator {
    /// Context passed to each allocator method.
    void *ctx;
    AK_AllocatorFunction f;
} AK_Allocator;

To understand this, let's look at a potential implementor:

AK_AllocatorReturn
a_libc_based_allocator(void *ctx, AK_AllocatorMode mode_kind, AK_AllocatorParams params) {
    // this implementation in particular has some baggage related to alignment.
    // don't pay too much mind to it if it doens't interest you.

    (void)ctx;
    switch (mode_kind) {
        case AK_AllocatorMode_Alloc: {
            size_t total_size = params.alloc.size_bytes + params.alloc.align + sizeof(uint8_t*);
            uint8_t *unaligned = malloc(total_size);
            if (!unaligned) return (AK_AllocatorReturn){ .alloc.ptr = NULL };

            size_t to_ret_unaligned = (size_t)unaligned + sizeof(uint8_t*);
            size_t aligned_int = ak_align_up(to_ret_unaligned, params.alloc.align);
            
            uint8_t **header_ptr = (uint8_t**)(aligned_int - sizeof(uint8_t*));
            *header_ptr = unaligned;

            return (AK_AllocatorReturn){ .alloc.ptr = (uint8_t*)aligned_int };
        }

        case AK_AllocatorMode_Free: {
            uint8_t *original_ptr = *((uint8_t**)(params.free.ptr - sizeof(uint8_t*)));
            free(original_ptr);
            return (AK_AllocatorReturn){0};
        }

        case AK_AllocatorMode_GetDefaultPreAllocation:
            return (AK_AllocatorReturn){ .get_default_pre_allocation.size_bytes = 1024 * 1024 };

        case AK_AllocatorMode_GetFlags:
            return (AK_AllocatorReturn){ .get_flags.flags = 0};

        default:
            ak_unreachable();
    }
}

Compilers like to compile dense switch statements into jump tables. Mechanically, this is very similar to a vtable. The assembly would look something like this:

cmp rsi, 3
ja .the_default_case ; if mode_kind > 3, jump to default case
lea rax, qword ptr .the_jump_table[rsi*8] ; load the jump target
jmp rax

; imagine the code for each case is right here

.section .rodata
.align 8
.the_jump_table:
    .quad .case_Alloc                  
    .quad .case_Free                   
    .quad .case_GetDefaultPreAllocation
    .quad .case_GetFlags

To execute this jump the CPU still has to ...

figure out what .the_jump_table[rsi*8] is,
load the memory address behind .the_jump_table[rsi*8] (explicitly into rax for clarity),
load the machine code behind the address in rax into the cache,
and set the program counter to the address in rax.

So why is this at all faster?

In a vtable each pointer points to a different entire function. This means it will likely be very far away from the branch site in the binary. However, In the case of the jump table, even if the jump table itself may cause the cache to miss (being that it is in .rodata rather than .text), it is highly likely that the target of the branch will always be roughly local to the branch site and every other branch.

There are other reasons too, like that that compilers will have an easier time optimizing around them, since they can prove the control flow surrounding them.

note: I framed the villain here as the "pre-fetcher" as a pedagogical falsehood since this isn't an article about CPU architecture, and because I'm not qualified to write one of those. The actual enemy here is the indirect branch predictor. If you want an interesting -- albeit dated -- paper on indirect branch prediction that explains this very well, there's one here.

If you can explain how wrong I am in 300 words or less, email me and I will quote and credit you here.

Arenas, Again

Almost 1000 words later and we still know nothing about how much memory to give the arena. What a terrible article.

There are three common answer to this:

Pick a number.
Pick a really big number and use virtual memory.
Grow the arena (somehow).

Importantly, you cannot just realloc the buffer. If there exists a single pointer to anything in your arena in your entire program state, said pointer would be instantly invalidated.

Akimbo's arena grows by adding a new "slab" (I am aware this term has prior art, but nobody cares) to a "chain." Each slab looks like this:

typedef struct
AK_Slab {
    // these are called up/down rather than next/prev so it's easier to visualize
    // them as a physical stack.
    // not like a "the stack grows down" kind of stack, but a real-world stack of
    // something like paper.
    // next and prev don't mean all that much in this case regardless, since the
    // "next" allocation can actually be "downwards" on this stack.

    struct AK_Slab       *up;
    struct AK_Slab       *down;

    size_t                cap;
    uint8_t _Alignas(16)  buf[] ak_check_bounds(cap); 
    // some writing may be coming soon about ^this bounds checking macro
} AK_Slab;

note: That [] syntax you see on the buf member is C99 flexible array member (FAM) syntax. All it does is fix the issue where you would have had to manually pad a struct and/or invoke nasal demons to have some sort of header/payload structure.

To summarize the snippet from the beginning ...

If I pasted this again, this article would be taller than me, but you can jump back to it here. If you're reading this on a web page, you'll see a "jump back" link to get back here.

... the allocator works approximately like this:

Plan A) If there is enough space in the current slab, take some memory out of it and give it back to the caller.
Plan B) If there's not, we have a "recycled list" of slabs to choose from. Find a slab from there and give part of it back to the caller.
Plan C) If neither of those can happen, ask the host allocator for new memory. The amount of memory you ask for is either some caller-set default value, or the minimum amount of memory needed to fit the requested allocation, aligned.

The primary benefit of this approach is that depending on that caller-set default allocation size -- let's call it size -- the allocator may assume the behavior of different kinds of arenas. If size is 0, then you always allocate the exact size of each allocation. This is inefficient, and will use a lot more memory in the long term, but you end up with a pseudo-garbage collector. If size is something more reasonable, like 4 MB, you end up with an arena that takes up a reasonable amount of address space, and is capable of requesting more. If size is massive, like 64 GB, you end up with a virtual memory-driven allocator that may take up a massive amount of address space, but is by far the fastest version because, in practice, you will never see any branch other than "Plan A."

All of this is under a unified abstraction where the caller gets fine-grained control over the memory consumption habits of the callee, without the ability or necessity for it to micromanage lifecycles.

The Scoping Mechanism

The only other piece of this is "what do I do when I'm done with this memory?" The answer is best understood with a usage example:

void
do_a_thing(AK_Arena *arena) {
    AK_Scope scope = ak_push_scope(arena);

    uint8_t *some_memory = ak_arena_alloc(arena, 1024, 32);
    if (some_memory == NULL) {
        goto out;
    }

    use_the_memory(some_memory);

    uint8_t *some_more_memory = ak_arena_alloc(arena, 102404837040, 32);
    if (some_more_memory == NULL) {
        goto out;
    }

    laksdfjlkasdjflkjl(some_more_memory);

out:
    ak_pop_scope(arena, scope); // "free" both at once!
}

This is relatively straightforward. When you're done with the function, you free all of the things you allocated.

This is really simple to implement if you don't have a linked list of slabs to deal with. I do, so the implementation looks like this and was about as pleasant to write as swallowing a live pufferfish:

AK_Scope
ak_push_scope(AK_Arena *arena) {
    return (AK_Scope){
        .offset = arena->current_offset,
        .slab = arena->top_slab,
    };
}

void
ak_pop_scope(AK_Arena *arena, AK_Scope scope) {
    if (ak_likely(arena->top_slab == scope.slab && scope.offset > 0)) {
        arena->current_offset = scope.offset;
        if (arena->top_slab != NULL) {
            ak_asan_poison(arena->top_slab->buf + arena->current_offset, arena->top_slab->cap - arena->current_offset);
        }
        return;
    }

    AK_AllocatorFlags flags = ak_alloc_get_flags(arena->host);
    if (flags & AK_AllocatorFlag_NoRecycle) {
        ak_unreachable("TODO");
        return;
    }

    if (ak_unlikely(scope.slab == NULL)) {
        ak_arena_recycle_all(arena);
        arena->current_offset = 0;
        return;
    }

    AK_Slab *to_recycle = scope.slab->up;
    arena->current_offset = scope.offset;

    if (to_recycle != NULL) {
        AK_Slab *prev_top_slab = arena->top_slab;
        arena->top_slab = to_recycle->down;

        // first, we break the chain below the final slab we want to recycle.
        // this forms a chain like this:
        //
        //                  (nil)
        //                    ^
        //                    |
        //             [prev_top_slab]
        //                    ^
        //                    |
        //                    v
        //                ..........
        //                    ^
        //                    |
        //                    v
        //               [to_recycle]
        //                    |
        //                    v
        //                  (nil)
        //
        //            [the new top slab]
        //
        // then, we recycle from the top slab all the way down to that point.
        // this one is confusing, so close your eyes and think about it.

        // break the chain
        if (to_recycle->down != NULL) { 
            ak_assert(to_recycle->down->up == to_recycle);
            to_recycle->down->up = NULL;
            to_recycle->down = NULL;
        }
        ak_assert(prev_top_slab->up == NULL);

#       ifdef AK_FEATURE_ASAN
        {
            AK_Slab *iter_slab = to_recycle;
            while (iter_slab->up != NULL) {
                ak_asan_poison(iter_slab->buf, iter_slab->cap);
                iter_slab = iter_slab->up;
            }
        }
#       endif // AK_FEATURE_ASAN

        // migrate the list
        if (arena->top_recycled_slab != NULL) {
            ak_assert((arena->top_recycled_slab)->up == NULL);
            (arena->top_recycled_slab)->up = to_recycle;
        }
        to_recycle->down = arena->top_recycled_slab;
        arena->top_recycled_slab = prev_top_slab;
    }
}

`AddressSanitizer`

You certainly noticed AK_FEATURE_ASAN, ak_asan_poison, etc. seasoning the code. These interface withAddressSanitizer (ASan).

Who is ASan?

A grossly over-simplified explanation: ASan deems every single eight-byte region of your code either "naughty" or "nice." If you access (read to or write from) a naughty region, you crash, and get a letter from ASanta that read like this:

==3543795==ERROR: AddressSanitizer: use-after-poison on address 0x7f7bd22fe870 at pc 0x55f161351120 bp 0x7fff5d8e9520 sp 0x7fff5d8e9510
READ of size 16 at 0x7f7bd22fe870 thread T0
    #0 0x55f16135111f in main tools/mirv.c:4293
    #1 0x7f7bd2427780  (/usr/lib/libc.so.6+0x27780) (BuildId: 503200d7fda94a5dc6058d7e0694e5d1dcb2e372)
    #2 0x7f7bd24278b8 in __libc_start_main (/usr/lib/libc.so.6+0x278b8) (BuildId: 503200d7fda94a5dc6058d7e0694e5d1dcb2e372)
    #3 0x55f161316334 in _start (/home/mike/repo/libgrad/out/tools/mirv.out+0x17334) (BuildId: 6eb12e75e7167875943f7aa08ec0a14320dbcd51)

If you read from a nice region, nothing happens.

By default, if you enable ASan -- which you can do by compiling your code with -fsanitize=address -- every region that you probably shouldn't be looking at (like stuff that isn't a heap/stack/data region allocation), is already naughty. It also pads each valid region with a proportionate amount of poisoned memory to catch over/underflows.

However, ASan knows absolutely nothing about your own custom allocators. If you want safety for those, you can ...

Instrument the code!

It all starts with a macro soup ...

#define AK_ASAN_PADDING_BYTES 16
#define AK_ASAN_BYTE_GRANULARITY 8

#if ( \
    (defined(__has_feature) && __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)) && \
    !defined(AK_NO_ASAN) \
)
#   include <sanitizer/asan_interface.h>
#   define AK_FEATURE_ASAN
#   define ak_asan_poison(ptr, len)   ASAN_POISON_MEMORY_REGION((ptr), (len))
#   define ak_asan_unpoison(ptr, len) ASAN_UNPOISON_MEMORY_REGION((ptr), (len))
#else
#   define ak_asan_poison(ptr, len)   ((void)(0))
#   define ak_asan_unpoison(ptr, len) ((void)(0))
#endif // defined(__has_feature) && __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)

ASAN_POISON_MEMORY_REGION marks a range of addresses as naughty, and ASAN_UNPOISON_MEMORY_REGION marks them as nice. These operations are idempotent.

Because of a certain shadow memory mechanism, you should only ever mark regions of at least eight aligned bytes as naughty (or multiples thereof). This is AK_ASAN_BYTE_GRANULARITY.

AK_ASAN_PADDING_BYTES is a constant because it's simple, and is enough to catch most over/underflows. AK_Slabs are padded internally and externally like this:

    slab starts here -> |                       inside the slab                                                  | <- slab ends here
*************************--------**********************-------------------**********************-----------------*************************
[default poisoned memory][header][user-poisoned-memory][actual valid data][user-poisoned memory][more valid data][default poisoned memory]

This is trivial to implement in an arena allocator. If all of the internal memory is poisoned by default, all you have to do is prepend a few bytes to each allocation, and you will never have any bugs ever again.

Aside: Zig

Zig the programming language is good. Zig the programming language and standard library is not as good.

This may be an inherent property of standard libraries in general, but Zig's arena allocator is particularly guilty.

I decided a couple weeks ago to shout into the void about this on the internet. I believe I said it best when I said ...

it is thread-safe (which makes very little sense for an arena, but has to be that way because it gets type erased), gives you no fine-grained control over lifetimes (because it can't since technically multiple threads can use it at once), if you use it idiomatically, you still have to write free calls everywhere (which mitigates much of the benefit), and essentially ignores resizes. it is an afterthought in the purest sense.

In retrospect, I may have been upset over electricity in a computer.

:w,

Mike