bitofhope

This site seems to be made by Drew DeVault who also runs sourcehut.

Sounds like you're suggesting a causal relationship the other way, though. As per this explanation, putting effort into debugging edge cases will statistically cause the comments to swear more.

Rorschach test for programmers: give your confident gut feeling explanation for this phenomenon.

I'll do mine: there's likely a correlation between needing to maintain a professional conduct which includes forgoing foul language (you're programming at work) and writing code under time pressure where getting a product ready for release is more important than strict adherence to clean programming practice (you're programming at work).

Everyone post your favourite conjecture!

I believe "go bananas" is a bit of metonymy from "go ape", possibly through "go apeshit", with the idea that bananas are something of a precursor to primate excrement.

Paying my respects to a pioneer.

I started a project to implement a LZ77 decoder in Game Boy assembly to see if it could compress the sprites in Pokémon Red and Blue versions better than the algorithms actually used in the game. Results are inconclusive so far, but it's been an enlightening experience.

Just a security patch, but I like seeing NetHack featured.

Looking forward to 3.7 where they finally address a glaring omission where up until now deities have been weirdly indifferent about people vomiting on altars.

The expression ((INT32_MAX / 0x1ff) <= x) is well-defined and will not cause overflow for any value of x of type int32_t. There is nothing to "optimize away" because there are no inputs that would invoke undefined behavior.

The original code was like this:

        if (x < 0)
            return 0;
        int32_t i = x * 0x1ff / 0xffff;
        if (i >= 0 && i < sizeof(tab)) {

(x * 0x1ff / 0xffff) can only be negative if (x < 0), which can be ruled out because the function would have returned already, or if a signed overflow has occurred, which is undefined behavior so anything can happen. The compiler can remove the (i >= 0) check because the only way it's false is if undefined behavior has already been invoked.

If you add the overflow check you quoted before the assignment, the compiler can still optimize away the (i >= 0) check like before with the same reasoning. Only this time the function will return before an overflow would occur.

The point of the "sledgehammer principle" described in the article is that UB checks must occur before the UB might be invoked and branch away. You obviously can't do this either:

    int i = 2 / x;
    if (i != undefined) {
        return i;
    }
    return 0;

Instead, you'll have to do something like:

    if (x != 0) {
        int i = 2 / x;
        return i;
    }
    return 0;

I'll argue for it not being cheating in this case. Consider this C quine:

    #include <stdio.h>
    int main(int c,char** v){char*s="#include <stdio.h>%cint main(int c,char** v){char*s=%c%s%c;printf(s,10,34,s,34,10);}%c";printf(s,10,34,s,34,10);}

Surely this should count as a non-cheated quine? Still, parts of the code (namely, the contents of string s) are embedded directly in the binary:

    % clang -std=c99 -pedantic quine.c -o quine; strings quine | grep include
    #include <stdio.h>%cint main(int c,char** v){char*s=%c%s%c;printf(s,10,34,s,34,10);}%c

Even though parts of the original source survive in the binary and are passed as pointers to a print function, the source code itself doesn't get read at compile or runtime (aside from being read once into the compiler).

If it's OK to read parts of the loaded binary to use as strings, I don't see why it wouldn't be OK to read the whole loaded binary, as long as you touch the source code file. I'd simply accept that the platform allows for some fairly trivial quines.

Anyone know any good articles, tutorials or books about ABI design? How did we end up with what we have now, what lessons are there to learn? How would you go about designing a new one from scratch? Would this fall more under operating systems or compilers discipline?

I yearn for a world where hard disk partitions are a memory of primitive times past confined to the minds of retrocomputing enthusiasts. I want my system board to have a firmware that can detect common variants of volume management including LVM and zpools, perhaps that thing Windows has that's kinda like software RAID for people into that kind of thing, perhaps even stuff like OpenBSD's softraid stuff.

1. Find physical disks that may be a part of a managed volume group/pool 2. Find logical volumes and file systems on the volume pools 3. Mount a filesystem by some configurable logic 4. Load and execute a kernel from the filesystem

Having to allocate the first "blocks" on the imaginary "sectors" of my SSD (or even worse, a virtual disk drive) for some arbitrary amount of space formatted in possibly the most barebones filesystem still in mainstream use feels quaint and irritating and limits my ability to use that disk in a larger storage pool.

UEFI is an overcomplicated specification with lots of wintel baggage, but most of it doesn't personally offend me. What does is that UEFI had the chance to abolish disk partitioning, but instead enshrined it. And added mandatory FAT32 to add insult to injury.

My main laptop and desktop each have a separate disk for the EFI system partition. The former uses systemd-boot and the latter ZFSBootMenu. This way I have a maximum of one partition per disk. It's not ideal, but I like it better than the usual solution.

The disks in my zpool show up as having partitions 1 and 9, but I consider that an implementation detail since I never need to treat the disks as anything other than entire disks in a pool

OCR hardly needed. Just read /dev/text.

I don't think the mouse chording is that essential to Plan 9. It's how rio and acme work, but those programs can be replaced without throwing away most of the OS concepts. I think you could absolutely create a Plan 9 UI that, for example, uses vi-like key bindings to jump around windows and text. Nobody's just done it yet and hardcore users are happy enough with what they have for now.

There are workloads where shell scripts are the so-called right tool for a job. All too often I see people writing scripts in "proper" languages and calling os.system() on every other line. Shell scripts are good for gluing programs together. It's fine to use them for that.

Likewise, I was filling out the survey while not on my work machine where I use emacs.