#ifdefs — Public Fediverse posts

This week started awful; from Sunday to Wednesday morning I was basically too sick to get out of bed, or even to eat. After that, it got better, and I did some sketching, cooked some dinners and tried to get back into the #krita release process.

Next week is the big release: the stable 5.3.0 and the experimental Qt6-based Krita 6.0.0. Same codebase, lots of #ifdefs.

Everything seems to be ready, from notes to announcement -- for the video @davidrevoy thanks!

#ThatWasTheWeek

My week: https://lists.haxx.se/pipermail/daniel/2026-January/000143.html (email sent to 486 subscribers!)

bug-bounty and hackerone, exposing silly, asking me, rate limiting, features, DNS and curl, #ifdefs

@avidrissman
So many #ifdefs and prefs 😁

Another I remember is how tab navigation works on macOS compared to other OSes.

@gruber

@cuddlebug looking at include/curl/system.h where a large amount of #ifdefs are used, it is clear that some are accepted but some others are not, quite arbitrarily from what I can tell

They made a few interesting decisions:

1. Rather than installing every SDK on everyone's computer, they just send the compiler along with the sources to compile

2. They use something that sounded like a regex search to find the #includes, and package all these headers up with the file to be compiled. This ended up not working very well because they're not actually running a full preprocessor, so they can't handle things like #ifdefs. (For comparison, distcc runs the preprocessor locally)

2/3

They made a few interesting decisions:

1. Rather than installing every SDK on everyone's computer, they just send the compiler along with the sources to compile

2. They use something that sounded like a regex search to find the #includes, and package all these headers up with the file to be compiled. This ended up not working very well because they're not actually running a full preprocessor, so they can't handle things like #ifdefs. (For comparison, distcc runs the preprocessor locally)

2/3

They made a few interesting decisions:

1. Rather than installing every SDK on everyone's computer, they just send the compiler along with the sources to compile

2. They use something that sounded like a regex search to find the #includes, and package all these headers up with the file to be compiled. This ended up not working very well because they're not actually running a full preprocessor, so they can't handle things like #ifdefs. (For comparison, distcc runs the preprocessor locally)

2/3

@claus

You're also not answering questions 😎

Really, some #ifdefs is the issue? How many cross-compilers are there involved?

@blyxyas

@robertmx Indeed. Or they were told not bother. And, seriously, how many #ifdefs and make file adjustments do you really need? 🤔 I wonder how much Intel and AMD has to do with this...

So, apparently, some Linux distros, and library maintainers, are considering, or even in progress of, to drop support for 32-bit architectures? 🤔 Here's an honest, and quite restrained question: what shit-for-brains decision maker came up with that brainfart? 🥸

Are you worried about addressing space? CPU performance? Bus performance? Too many #ifdefs ... What? Let's hear the golden arguments for this clever line of thinking?

#32bit #64bit #devops #coding #programming #programmers #Linux

I'm finding I'm removing a lot of my Mac Catalyst #ifdefs in my apps and turning them into runtime checks to enable advanced features on iPad, too. I think this is the 'missing link' between iPad and (Mac Catalyst + visionOS) that I talked about two years ago — the common ancestor that was missing between the three UIKit platforms. We finally got it. And it only took some fairly 'small' tweaks to iPadOS to make it viable — sensible windowing & a menu bar. But that enables whole new class of apps

@ret just as a gentle counterexample, @adafruit has had good success generating skeleton code from datasheet PDFs. You feed in the datasheet and it spits out all the #ifdefs for every register, every bit in the register, etc etc. That sounds quite nice to me.

@leitzke yes to via, and their own stuff too -its just the idea of building your own KBC firmware appeals. I have seen the code used in HP laptops which was a nightmare of #ifdefs in C code which controlled the battery charger and everything else on the I2C bus. QMK looks better!

@mgorny from an upstream point of view, there seems to be some friction when the distro says "we want to use xxx dep instead of yyy dep please add just one more config option" and it's not in our test matrix and isn't something we want to support or maintain #ifdefs everywhere. e.g. in fwupd points of contention are systemd, bash, gnutls, flashrom, libqmi, glibc, sqlite, libcbor and most recently pygobject. It's exhausting trying to support every distro.

Per @cratermoon, Emacs still does `unexec`. https://lwn.net/Articles/707615/ Actually, the unexec code deserves a place in a list of big influences on my life. You see, in the early ‘80s, there were many more computer architectures and Unix variants than there are today. The unexec code was very sensitive to both, so there were a lot of C #ifdefs. As I was the maintainer for the Gould PowerNode¹, I watched `unexec` change over time. And… (1/2)

Q: Application XY misbehaves or crashes at runtime when linked against musl

Usually this is because the app has hardcoded glibc-specific assumptions or wrong #ifdefs. See Functional differences from glibc. The most common causes are expectations of gnu getopt behaviour, iconv usage on UCS2 with assumptions that BOM is processed and the byte order detected, assuming that off_t is 32 bit, and assumptions that pthread_create will create sufficiently large stacks by default (crash situation).

right, so

…what is Alpine doing then?

https://wiki.musl-libc.org/faq

@bruteforce From a user's standpoint, sure, why not, if it's doing the job for you then go ahead.
From a developer's standpoint, I have my reservations about socat.

The reason why I'm advocating for one super-[client|server] per socket type is that 1. it's not a domain where you need programmatic flexibility (you know when you want to use a vsock or a TCP socket, there's rarely a case where it depends on external input), and 2. it's easily scalable to new socket types when they come out. And so, vsockclient doesn't have to be "the thing that works on Linux", it can be "the thing that works on any system that supports AF_VSOCK", and you don't need an #ifdef forest - either it will build on your system or it won't.

There's an additional reason for super-servers: super-servers can track connections, e.g. to limit DoSsability by a single client address, so my super-servers maintain a pid->clientaddress map. But the client address is socket-type-specific, so the data structures change a bit depending on the socket type. For AF_INET, the client address is 32 bits; for AF_INET6, it's 128 bits (and factoring that properly in the same executable without wasting space in the IPv4 case took a bit of work); for AF_UNIX, it's a uid_t, so 16, 32 or 64 bits depending on the system. I haven't looked at what it would be for AF_VSOCK yet, and even less for future socket types I have never heard of.

So, I like the idea of tcpclient, ipcclient, vsockclient being separate binaries, being built independently.

socat, just like nc, is the opposite: it does portability by extensivity. When a new socket type comes up, it needs to be integrated into it; and you need #ifdefs everywhere to make sure you can still build on whatever system that may or may not support this or that socket type. And good luck adding all the new syntax to parse the new socket addresses on the command line. I don't even want to imagine the complexity of socat in listen+fork mode if it tries to track client connections!

Basically, the socat authors didn't make it easy for themselves, or for packagers; I think it's a maintainability liability, which you don't have to care about as a user, but which I think isn't healthy for the ecosystem as a whole in the long run.

@timbray @whenning I was going to suggest you use m4, but it sounds like you already have a plan.

I understand the value of #ifdefs but lexically directed conditional compilation causes just far too much trouble. The potential for abuse is too high. It's simply not a good idea to have them generally available. Build a custom one for your problem and we'll all be happier.

@whenning @timbray Not for #ifdefs they won't.

@fst the biggest explanation is C. But sure, there are quite a number of #ifdefs and more to make sure it works on as much as possible.

Also: many of the ports to these different OSes were never contributed back to us so I don't actually know how much extra patching that was necessary. Or not.

Playing with the llvm-mos 6502 assembler, and it cut the code size of this c64 demo in half. There's still a long way to go wrangling #ifdefs and inline assembly clobber lists, but it looks promising. It's still weird to use an executable the size of 311 floppy disks to compile a 1.2kb program...

Ahh I fell for the staying work at late trap. Oh nooo.

I'm surgically replacing C++ library A with C++ library B (with almost but not entirely the exact same API).

Which leads to all sorts of fun namespace collisions when there's too much code using it to swap it all out in a single commit. So then you end up with #ifdefs EVERYWHERE. Just a sea of #ifdefs. Also Bazel will actively try to prevent you from doing this kind of stuff.

But excuses excuses, I'll go home at 5:00 exact from now on.

@litherum First glance at some of the code samples, it strikes me as unsurprisingly WebGPU-ish. (There's only so many ways to wrap that set of underlying APIs, % some specific compromises.) Feels like their "tiny" single triangle example has an awful lot of #ifdefs. Not clear on if they're using GLSL as their primary shading language or ingesting a bytecode and just using a compilation helper lib? Would be interesting to do a deep dive comparison with WebGPU.