Notices by Fabian Giesen (rygorous@mastodon.gamedev.place)

This instruction:
mov [rDest + <index>], ch

under these conditions, when overclocked a bit, once the machine has "warmed up", seems to have around a 1/10000 chance of actually storing the contents of CL instead of CH to memory.

(this was "fun" to debug.)

The workaround: when we detect Raptor Lake CPUs, we now do

shr ecx, 8
mov [rDest + <index>], cl

instead. This takes more FE and uop bandwidth, but this loop is mainly latency-limited, and this is off the critical path.

What's that mysterious workaround?

Core Huff6 decode step is described in https://fgiesen.wordpress.com/2023/10/29/entropy-decoding-in-oodle-data-x86-64-6-stream-huffman-decoders/

A customer managed to get a fairly consistent repro for transient decode errors by overclocking an i7-14700KF by about 5% from stock settings ("performance" multiplier 56->59).

It took weeks of back and forth and forensic debugging to figure out what actually happens, but TL;DR: the observed decode errors are all consistent with a single instruction misbehaving.

I've been around _just_ long enough to get pretty much the entire history of the etymology of computer storage device names to get hella confusing

When I was a small kid, floppy disks were actually floppy (5.25") and contained actual spinning disks, floppy disk drives contained the thing that drove the disks (i.e. the motor), and hard disk drives had hard disks (metal platters) and the thing that drove them all in one package. Fair enough.

Not long after, we got 3.5" floppies that had a hard plastic shell and were not actually floppy anymore. Still called them floppies.

So a 3.5" floppy drive is actually a drive for a disk in a 3.5" hard shell but whatever.

Then we got other magnetic removable storage formats that were also all hard-shelled but whatever.

Then audio CDs got adapted for data storage and we got CD-ROMs with CDs (and later DVDs) that were actually disc-shaped, unlike floppies where the actual storage medium was disc-shaped but the overall package wasn't.

and then we got solid-state storage and the entire terminology is just terminally bonkers now

we have "disks" that are neither diskettes nor disc-shaped (the actual chips are rectangular), "disk drives" that don't interact with dis[ck]s and don't drive anything (not in a mechanical sense anyway), and the "solid-state" part refers to no moving parts but of course the stuff with moving parts is also all in a solid state of matter, generally

in short, two of the three words in "solid-state drive" refer to the thing it's got in common with literally all the other competing storage technologies and the remaining word describes the one thing it doesn't actually do, definitionally

FOR IMMEDIATE RELEASE

Santa celebrates 50 years "out of list-making business"

NORTH POLE. May 12, 2025

Santa is celebrating 50 years without the naughty/nice list. "We stopped doing it in 1975 since it felt out of touch with the times then; these days, with frequent data breaches, privacy regulations, COPPA, GDPR... frankly it feels like a liability nightmare, I don't think anyone would even seriously consider doing this now. I mean, a naughty list leak. Can you imagine?"

a barometer is just a mic with a narrow frequency response centered at 0Hz and I'm tired of pretending it's not

don't @ me

so I don't want to advocate for opening cans of worms but I _would_ like to know who makes these canned worms, and who stocks them everywhere

FUN FACT: if you place a 1080p image so that its width (long axis) lines up with the width (short axis) of a NFL regulation football field, your pixel grid has exactly 1 dpi

just to fuck up US customary units even further, I recommend that that be the definition of dpi going forward

(de.) Hans Zimmer = (en.) John Carpenter

Like yes, I agree that it sucks that stb_image has a lot of exploitable bugs that often are around for months or years at a time but at the same time... we're completely transparent about this. Don't put this code in a security-sensitive context, especially if you need timely updates. We realistically can't serve that need and we have never claimed that we could.

I do have plenty of code that I professionally maintain (you know, at work, where I get paid to do so) where security issues get handled ASAP but... that's work.

Like that's actual work. I do that (and other support, and other coding) full-time every week. I'm not going to spend my weekends doing the exact same thing I do at work too. (I did for a while and it was _bad_ for me. I'm not going back.)

...so what's my point here?

For foundational libs (including xz/liblzma) tons of people depend on, it sure would be nice if, assuming there are people who _want_ to be full-time maintainers, get to actually be paid for doing so.

For something like the stb libs? I really don't know. I don't think we're foundational. If those libs disappeared overnight, nothing terrible would happen, people would just use other alternatives.

And "any open-source lib anywhere in the wild must be up to professional quality standards and respond to all bug reports in a timely fashion" is also a bullshit standard to apply to anything. It just doesn't work that way.

And the reason I'm writing a whole thread about this is that fundamentally, I refuse to treat this as a problem when a lot of discourse around open-source libs very much wants to pretend that it is.

I don't know, man. Some projects just exist to scratch a very particular niche itch and are maintained by people who have plenty of other things going on in their life and... that has to be OK?

For example, I usually take some time off around Christmas, and _usually_, 1-2 weekends around that time I spend on stb lib maintenance, because I'm on vacation anyway so it's not a context switch from work, and the weather is usually miserable where I live around that time.

2023 that didn't happen because I badly sprained my ankle early Dec and then got a cold in early Jan, so all my winter holiday time end-of-2023/early 2024 was spent being sick in some form or other.

Most of the maintenance I end up doing is security fixes in stb_image. These take a comically long time (often these stay open for more than 6 months).

I don't know what to say other than that stb_image has always had a note up top, which currently reads " Primarily of interest to game developers and other people who can avoid problematic images".

stb_image was _always_ meant for indie games and throwaway tools where you're in full control of the data.

The code was not originally written with security in mind and it shows. Now we do treat security bugs as bugs and _will_ fix them, eventually, but they're on the same schedule as any other bugs and feature requests, which is to say, realistically we do a real release once or twice a year.

Filing 20 bug reports will not make us respond any faster. Nor will filing CVEs or whatever.

Yes, I agree that it's not great that we don't get to these sooner.