How SerenityOS declares ssize_t

I'm not a C developer at all, but this looks like bragging about a clever trick; when it comes to these things (and most code for that matter), I'd avoid clever tricks like the plague. Just write it out logically and as simple as possible. You're not saving much time / effort by writing out, and clear is better than clever. Code size is never an issue.

Somewhat off-topic, but what's the :^) supposed to mean?

I've always parsed it as "the previous statement was intentionally wrong or irritating", sort of like the /s sarcasm tag except it can also denote trolling those who aren't in on the joke. I'm unsure whether it's used as a normal smiley here or whether there's something I'm missing.

My understand is that :^) represents a more devious/cheeky smile. I think this is more common than strictly a trolling/sarcasm usage, though you could see how it could fit there as well under my definition.

I agree on the practicality aspect. When programmimg in C, one learns to accept these preprocessor hacks.

When programming in C++, where limited compile and type metaprogramming exists, one is constantly hitting the limits and it causes endless frustration. I go through a mini cycle of grief until I give in and use a macro, or an otherwise less elegant implementation.

You're right in that it has taken years (decades, even) to standardise some better alternatives to macros. But even now C++ lacks some of their power.

I have to wonder how much faster alternatives would have been implemented, if macros weren't "good enough" for so many use cases.

> #elif SIZEOF_SIZE_T == 2 // LOL

Fun fact - for a while, this was true for the third most popular processor architecture in the world, one that most people haven't heard of.

CSR (the bluetooth chip maker) was originally a spin-out from Cambridge Consultants, and their chips were for years based on a Cambridge Consultants processer design called XAP. As CSR had made billions of devices, XAP was likely right up there in terms of number of processors made.

XAP was unusual in a couple of ways (at least unusual compared to the fairly universal modern design). Here's a fun set of statements that all evaluate to true:

    sizeof(uint8_t) == 1     // So far so normal, this is required by the C standard
    sizeof(uint16_t) == 1    // Surprise! BTW, uint16_t is defined as "unsigned int"
    sizeof(void *) == 1      // Weird
    sizeof(void (*)(void)) == 2 // Yes, function pointers are not the same size as data pointers

This is all completely legal according to the C standard. Fun fact, the size of a byte isn't "8 bits", it's technically "the minimum addressable size on your platform"[1]. On every modern processor design I know of, that is an 8 bit quantity, but the XAP only allowed you to address 16 bits at a time. Presumably this was for efficiency - the XAP was very low gate count for a fairly capable processor (at the time). 16 bits was also the size that the instruction set operated on, the "natural size for calculation" as described in the C spec, so that's the size of an int. This means that sizeof(int) == 1, which is a surprise to most people. It also means that you can't do tricks like "cast a uint16_t to an array of 2 uint8_ts" (which is non-portable also for endian reasons anyway).

The other unusual aspect is that it's a Harvard architecture, which separates the address space for code and data. Code size being large, this meant function pointers were 24 bit, whereas data pointers were 16. Code that assumed it could cast a function pointer to "void *" to put it in callback context could get a nasty surprise (usually a subtle one, because it only broke if the function was late in the address space).

This was what I worked on early in my career, it was a great education in writing C that was actually portable. If it ran on PC and XAP, then it would likely run on anything!

[1] This is why picky/anal engineers will refer to "octets" in a network protocol rather than bytes. Bytes don't have a meaning except in the context of execution, which obviously doesn't apply to a network protocol.