Alternative title: dyslexic man quits job to read articles full-time

C isn't a programming language... It's a lifestyle

Back when humor wasn't banned from compilers, I had heard of the "long long" and decided to see what it thought of a long long long. The error message was "long long long is too long."

Two programming languages kissing each other and realising they are both C is like having two blind folded cousins in a kissing booth.

18:51 C++ increments the value of C, but yields the old value

"Sometimes, I don't think I realize, just how much of shoulders we stand on"... So true.

Congratulations you discovered why C can run on literally anything with some sort of processing unit and memory (it's because the entire standard is up to the hardware's implementation).

"Hey, why doesn't Rust have a stable ABI?" Oh, hold my beer...

> You can't parse a c header Zig: skill issue

To C, or not to C.

Yah, C is the supreme authority from which all other languages, tools, apps are derived.

"Nothing better than C" - Linus Torvalds

What is long? It holds at least 32bits worth of data, says the C standard. It holds exactly 32bits of data, says Windows. It holds exactly a pointer, says Linux.

I worked on a commercial product, started in 1980s. The first public version was on the IBM AS/400 [now I5 series] and it used 128 bit addresses. The pain making it work was severe. Later on it was published for s390, Linux,Unix,Windows... both 32 and 64 bit... and that was relatively easy. The hard work had all been done.

The article author doesn't seem to know that the C libraries are themselves just a wrapper for the syscalls that actually connect to the kernel. the kernel is entirely language agnostic, but has a method that is specific to each CPU/ISA it's ported to that enables a function call to a protected kernel runtime level on that ISA (in x86_64 that is: load the function arguments and a code that specifies the function to be called into specific registers and then execute the SYSCALL instruction, but since this is specific to x86_64, different methods get used for arm, risc-V, MIPS, PPC, even x86_32). If you want to compile and create an executable without using the C libraries and their ABI, the answer is simple: implement the kernel interface directly. If you don't want to implement them all directly with your equivalent of an asm() directive, just implement one generic syscall instruction in your compiler that will spit out the right instructions for each architecture/OS you want to support and then make wrapped functions for each of the kernel routines you want to access. It'll be some work, but you can stop bitching for a while.

size_t: unsigned integer type than can address any offset within any memory section. ssize_t signed integer that covers at least [−1, ½(SIZE_MAX−1)] (NB!, the only negative value that is guaranteed to supported is −1) rsize_t: intersection of size_t and ssize_t. intptr_t: signed integer type that express any memory address and uses two's complement. uintptr_t: unsigned version of intptr_t. ptrdiff_t: this one is a real mess.

How long is an unsigned shlong?

Isn't __int128 a compiler extension? So different implementation in different compilers is expected. And you don't need glibc to create file you can make syscall directly

I have to say as a newbie that learning C has made me understand a lot of fundamentals better. In other languages it felt like the added abstraction didn't really allow me to see the inner workings as clearly.

Sadness. Don't blame C for only solving 90% of "computers are not all the same" problems. It was never a problem with C. Heck, as a C programmer, I also hate dealing with linkers, calling conventions, and ABI's. Its the ugly underbelly of software engineering. The alternative is we hard-code binary interfaces for every piece of hardware we might expect to interface with. Its the very reason libraries, drivers, and operating systems exist.

Well, the optimal C implementation for the hardware in a toaster and the hardware in a supercomputer are completely different, that's why its vague there isn't a one size fits all solution. C's flexibility for HW manufacturers was always its appeal.

size_t is used in std c/++ because it's the return type of sizeof. The reason they do *that* is because anytime you're working with arrays, indices, byte sizes, etc. are all times where that value can be potentially converted to/from a pointer or used as a pointer offset. That means it needs to be able to hold any value a valid pointer could so on 64bit machines it needs to be a 64 bit int, on 32 bit it needs to be 32 bits, etc. Thus size_t avoids all of the nonsense of int vs long vs long long, etc and avoids the hardcoded sizing of int32_t and just says "whatever the size of your pointer is the size of the integer you should use for indexing, here you go". C++ mucks this up a bit because it has extra large pointers in some cases due to multiple inheritance, v-tables, etc.

At which point do we throw everything away and do THE big rewrite?

Me overhere using custom types for everything and never using built-ins..... Ahhh i love c

The ABI suffers from having to continue to be "C". And C suffers from having to continue to be "the ABI". It feels like we'd need a software equivalent of the phonetic alphabet, i.e., a synthetic language that nobody actually uses, and doesn't even make sense on its own (no "grammar"), just for the purpose of creating well-defined interfaces. But then, that language would probably have to "talk C" too. Sigh...

C is like Pluto, and Pluto said: "Your mama thought I was big enough"

C is love, c is life and also goddamn nice

I've read their blog before/know who the author is: They have written the Rustonomicon, _the_ thing to read about unsafe rust. The "sounds like skill issues" by the Primagen at 6:20 and the chat at 6:23 "WTF? Even ChatGPT would do better than this article" made me once again realize that the Chat and often times The Primagen too have absolutely no idea about some part of programming.

I've had to deal with this at work. We have literal meetings over ABI/API compatibility and together design a header and review it before it ships. (I'm just a junior dev tho) Thankfully, there are standard methods to do this well and maintain compatibility, but it comes with extreme cost. When a new feature is at potential odds with the old one, and there is a change that old and new types can mix, then oh boy. For example, what do you do when multiple apps load your shared object. Shared objects are typically loaded only once into memory but mapped to different virtual addresses b/w apps. The object file has both the versioned APIs - v1 and v2. One uses v1, the other uses v2. But both the apps talk to each other. You'd think everything would "compute" in v1 but the second app does not "know" about the first app. Remember that struct members are just offsets from a pointer so if you get a v2 object from the second app but was created by v1, in your library you're reading out of bounds in your library ... but it's the fault of the second app! (It should've set the version to 1 instead of 2). I dreamed up this scenario, but I wouldn't be surprised if it happened at some point in time. Hey hey what if apps exported their ABI info as json :D along with the binary. Then we can just use that to interop. This would also allow languages to change layouts (as in consecutive members don't need to be in the same order in the binary as they are declared)

5:03 I would argue that's partially untruth. You could just do a wrapper around single every system call (this would require writing assembly) and you would be good to go. The major question is: are you willing to do that?

No more netflix = no more hoodie?

Seeing people argue about tools to get job done and disregarding where this tool shine is beyond me

size_t is the same size as the memory address size - 64 bit or 32 bit; It's also the type which the sizeof() macro returns. There is an equivalent signed version, ssize_t which is for functions which want to return a size in bytes or a negative error value

Tower of Babel. I hope I still speak Python after the collapse.

C avoids any ABI by design. Its up to the OS and architecture to do the ABI. The function calling convention (part of the ABI) is the prologue and epilogue the architecture probably suggests to include...

C is the means by which all is revealed.

One of the side projects I've been working on from time to time over the past few months is a compiler & runtime for my own programming language. I had actually put "external functions" in my list of things to do... I might reconsider. Or at least, reconsider making it compatible with anything else than some custom format, really.

My first job out of college was using mainly C on an HP-UX Unix machine in early 2000's. The app controlled time clocks, sent signals to machinery in the plant, etc. It had to be real-time. My boss and I would write some assembly to pull in because the C function wasn't fast enough. Great times!!! After my boss and I left that company around the same time I went to C# and never looked back. I still to other stuff SQL, Javascript, Go, etc... now at a robotics company I'm writing C++ for micro controllers. I still do C# / SQL there to communicate to the robots.

Same. Whenever I am doing C stuff, I (almost) always use bit-defined types like uint64_t unless I can't such as interoping with spicy Win32 stuffs which is distressing frequently for me since a lot of the stuff I do C/C++ stuff for is game hooks (speed run tools, randomizers, etc.) where my code will be injected into the process and I'll be working with Win32 and DirectX APIs a lot of the time.

Yea, int was supposed to be 16 bits on 16 bit CPUs, 32 bits on 32 bit CPUs and 64 bits on 64 bit CPUs, but they kept it at 32 bit for x86_64 because "changing it would break things" ( namely badly written software ). I have worked on a CPU where int was 24 bits and long was 32. Go figure.

30:50: How are you going to have int32_t on a 9- or 7-bit machine? And what are you going to do when you a size, a memory address expressed as an integer, or a difference between pointers? Sure, you don't need short, int, long, and long long, anymore as you have {u,}int_{fast,least}N_t nowadays, but there still are integer types where you don't want a number.

There is a reason why types that don't defined a set bit width are standard for C and C++. You can't guarantee that a particular platform will have a particular size. If you have just i8 and i16, but you need to write code for a platform that doesn't have either of those, what do you do? While this is EXTREMELY unlikely in a modern context, both C and C++ are obsessed with "backwards compatibility" Something once compiled for an DSP56000 should still be compile-able for an DSP56000 . I disagree with this stance, but i'm in the minority.

AI = Productivity goes up, quality goes down

9:10 its actually compiler dependant for example TurboC has 16 bit ints iirc

the solution going forward might be to have some 'link specification' layer.

The fun starts when you work on systems were the smallest addressable memory cell is 16bit wide, so your "char" is 16bit; this is true from some DSPs. This gives the mind blowing results that sizeof(uint16_t) is 1, and sizeof(uint32_t) is 2..

It is the best programming language ever, and I realized that after 15 years of programming in everything else and then revisiting C.

You can call these functions including the binaries of the required C libraries into your compiled code by calling them in assembly or machine code. But use them as your programming lingua franca is worse than use C.

The best thing objective-c and swift have are protocols from the small talk message based roots. It lets you do soft inheritance where things don’t have to conform structurally like memory mapping stuff in c

8:56 While the real sizes of those depend on the implementation of the data type, the minimum size for a short is 16 bits, 32 for a long and 64 for a long long. A short long would be the same as a short and a short short (half of a short) would be the same as a char.

It's not that C isn't a language. It's the only language. All these others are just newer C compilers

I love C in the morning.

8:53 Truth. For years I had longs defined in the dynamic types on my application platform/OS. I just never thought much about them. The system is adaptive, so the size isn't an issue. However, longs always require 'deviant' code since there is no agreed-upon size for them. So, "Removal of longs" is on my TODO list for my platform. No big loss.

31:08 is size_t supposed to be unsigned and same size as memory address?

Can't we all just get a long?

Hes got it backwards. C bends to arbitrary structure layouts and whatnot. He wants every other language to do that instead of C.

C MENTIONED LETS GO

C is not a language, it's something more!

I remember arguing with a professor's assistant decades ago about the notion of wobbly definitions. I felt, and still do to this day, that programmers need to know how big a number they can store in a given type, and they need to be able to rely on that. He made a vague, hand waving argument about how they don't really, and how software can be more portable if wobbly definitions are used. More portable? The definitions for things *change* when you port, and that makes software *more* portable? That's not obviously fallacious? Either I was missing something that I'm still missing to this day, or that fellow was just kind of ideologically captured. That reminds me of an argument I had with a high school calculus teacher about a theoretical baseball out in space slowing down on it's own with no external forces acting on it. I said if there's no friction or gravity or anything, won't it just go on in a straight line at the same speed forever? No, there would be some rate of change of it's speed, the teacher insisted. Sure there would, I said, but it would be zero. No, they insisted. It would be almost zero, but not quite zero. It would be an epsilon. (The closest thing to zero that's not zero.) Ok, so if it's non-zero, in what direction will it be? In the direction opposite the one it's moving in. Really? Moving relative to what? The ether? It seemed to me that the analogy he was making to try to explain what epsilon is was breaking down a bit. "Maybe we should be talking about a circumstance under which the formula describing the values we're tracking actually involves epsilon?" I got told by him and by class members not to argue with the teacher. I think I facepalmed at the time, and I still facepalm remembering it. Fortunately the calculus/physics teacher at the community college affirmed my understanding. I didn't tell my high school teacher. (One facepalm was sufficient.)

Programming is like a lake, a very old untouched lake with no fish in it. The surface is all nice and clear but deep down there's mud and decaying plant matter. I like diving deep in there cuz I like rolling around in that mud but it sure feels icky every time lol.

In embedded we always use int32_t, uint8_t etc. Makes life much simpler, I can't stand that most codebase for PC is 99% ints, long longs and other stuff.. Using anything else makes 0 sense and is forbidden by every dev. We do the same when writing embedded C++ code and we stay away from std:: and everything bloated from it.

Dennis Ritchie - the Johannes Gutenberg of the 20th century.

Terrible: that’s the long and short of it

I think what programming language authors forget is that there are standard ABIs like the SysV and Windows ABIs (these are not C ABIs). If you use them, you could just link with any language that has a compiler for that specific ABI. No need to parse any C code, just mark the function as external and let the compiler emit code that conforms to that ABI and then let the linker link stuff together. It's a widely known functioning interface that language authors somehow forgot how to use. Yes, I get that people don't want to deal with all of the object files but how else are you gonna glue two languages together.

We should make whatever ABI HolyC uses the FFI standard instead.

8:52 I call 64-bit integers "long" and Notch does so too as it seems, but in Python3's struct module a simple "long" is identical to an "int", a 32-bit integer. There you need a "long long". But I thought "long" meant "it's longer than the default"?

If you want the natively sized integer, use (s)size_t or (u)intptr_t. I think of "int" as the smallest "efficient" type. For serialization, use fixed sized integers, and remember to consider padding.

Now I feel old and way under knowledge. This debate of frustration takes me back to nearly the same debate in '71 (when my friends were introduced to BASIC) and again mid 80's (when MS published 7 volumes of Windows libraries. I am sure this was debated before my time as well. Each time the debate split folks into a couple of camps. Both sides said F-it I roll my own and those that dug into figuring out the next level.

6:44 Nnnnope! I'm actually in the process of writing a C/header parser. Yeah, it's a b!tch, but you just have to put in the work. But then again, I'm old school; I'm quite used to burying my head in code for days/months/years on a single project.

int wasn't increased from 32 bits to 64 bits because the C standard wasn't updated. 32 bit ints was more than big enough for the vast majority of use-cases. The same cannot be said for 8 and 16 bit ints.

9:20, it has the int8-to-platform-size_t as the precise integer. But if that doesn't need to be precise, and even more, 1 wants to make the app "future proof", a long will target the platform size, so that it'll keep being "upgraded" as platform size grows. It can even become faster throughout time, if the app was thought to make binary operations on 1 variable, if that is faster. long long then it's what it seems, twice the size, if allowed. short for the smallest or at least smaller than the middle 1, int. 12:23, cringe moment: I don't know what's this May 9th. 15:04, not all platforms allow this double the size. So something like int128_t is meant for a compiler error if not supported. long long means "the maximum possible signed size". So, if not supported, it may be shrinked back to 64 bits, since the user didn't express necessarily 128 bits.

C only got ”int” integers. Want it longer? use ”long int”, still not enough? use ”long long int”. Need an other bit? ”unsinged long long int”. Changed your mind, actually didn’t need that something shorter than an int? No problem ”short int” to your rescue. If you want values of specific byte lenght, use the standard integer types from stdint.h, here is a few examples: int8_t, int16_t, uint8_t.

3 minutes in and it sounds like he wants to make python.

6:21 "You Can't Acutally Parse A C Header" Dlang can do this! It has a fully functional built-in C compiler that handles the C include files (without using clang)

int was supposed be 64 bit on 64 platforms. But so many people used well... very poor programming practices in the 32bit era and just assumed type sizes. Of course when you compile for a new target this breaks shit everywhere.

"what about a long short? can you have a short long?" I recall a compiler for some embedded platform that had either long shorts or short longs (not sure which). They were 24-bit, in between 16-bit shorts and 32-bit longs.

"size_t" is supposed to be the maximum size a structure could possibly be on the given architecture. Though by now this basically assumes it is uint32_t on 32 bit systems and uint64_t on 64 bit systems because of how memory access works. However there could theoretically be systems that have native support for 64bit integers and might be seen as a 64bit architecture but have a 32bit or 128bit address space, which would lead to issues since in that case size_t would need to be uint32_t or uint128_t (which does not exist) Though technically the correct type to index a container doesn't have to always be size_t. It is officially defined to be std::::size_type which just happens to be size_t most of the time

Just a grumpy old embedded engineer here. The question is what your job is. If your job is to make software that must work on a CPU that has less than 256 pins or operating voltage more than 1.5V, you are most probaly left with only C/C++ toolchains. Assuming you want to avoid assembly. The hardware mentioned above is basically everything your world is operated by. Want something working above 80 degC? Something that should work on a wide voltage range? If one does not want to learn new assembly for each of the targets at hand, C is the language of the cheap hardware. To my surprise, the most vocal people against C is the ones who use joe, vi, emacs or some other -vintage- exotic editors.

C is basically a high level version of assembly language. Because of that it lends itself well to being a low level system language.

Loving the Zig callouts.

XKCD 927 was published in July 2011 and I am gratified to see the cycle continues unabated.

"Is a short long an int" LMAO

I really dislike articles which have a new paragraph for every single sentence. They probably do it, so the article looks longer.

This is why I'm so interested in Zig, I really hope that at some point it becomes a sufficiently good platform that, many developers will start to use it in the operating system world, and who knows one day we might have a Zig ABI instead of a C ABI, which will probably makes us a lot more productive and solves a lot of issues

You're funny to listen to man, subscribed! :)

this article doesnt quite grasp that my day job is writing the same c code that runs on your 128-bit processor... but for a 16-bit AVR. And with slightly different typing, it is surprisingly portable

Still a language, but also a protocol.

"Rust make people angry that things don't looks like Rust" After the last 3 years coding only in swift I can relate.

On the topic of size_t, isn't it supposed to be the width of pointer/memory address, thus is truely hardware defined and justified to be opaque?

9:00 When I was a programming student, I had a friend I'd correspond with by email every now and then exchanging homework assistance, and I'd just gotten introduced to C (via GCC) coming from Java experience in high school, and I personally maintain that the funniest exchange she and I had ever had was when I was messing around with the type system in C, learning about the sizes of different types, and managed to get back the error message "'long long long' is too long for GCC". Like "oh, 'long long', that's fine, but 'long long LONG'??? That's going too far buddy!" 🤣

"I haven't reached the disgusting layer" *uses Lua*

here it is a rare footage of a ThePrimeagen wearing a t-shirt instead of a hoodie

Each long should increase the number of bits by a random amount, and not by a multiple of eight, in fact, only by prime number amounts.

Around 33:00 Yes, there is a "triple long". It's called a "Long Dong Silver" and in size exactly two norm EU bananas ...

C is turing complete. And therefore it can run any (computational) program, or any algorithm you can come up with. Incidentally, CSS is also turing complete. CSS is actually a programming language.

Longs are not well-defined. That's the point. The type sizes change based upon the platform. It can be literally equal to an Int on some platforms. You must inquire using #ifdef kind of things to figure out what applies at compile time. The problem is not that C has no ABI, but that NO ONE clearly defined an ABI and said, "This is what we're using." In fact, if you do that, you're pushed into the world of JiT compilers. There is an easier way to do it: publishing a standard for defining interfaces that involves Linkers and Loaders doing some last-minute fixups between different binaries at load time. You'd basically assume a fixed ABI across all machines, then have the Linker/Loader inject helper transforms to the local environment. It's different from JiT only in that, once done for a given machine, it could easily be cached for the next run-time and there is (theoretically) no overhead that isn't necessary for ANY ABI abstraction to work on pre-compiled software. No one has written such a standard or modified a linker yet (that I'm aware). The alternative for fully-compiled code is this: "C is the standard OS-writing language. They must have C. Let's use C as a glue to patch together our interfaces."

There are some guarantees. But they aren't the ones you want. An int is at least as long as a char. A long is at least as long as an int. That sort of thing. Floats are easier since there is IEEE-754. If you want well defined integer type sizes, you're going to have to define them. I would use a uint64_t over a long long. As for size_t, I think that works out to the same length as a pointer. That is, sizeof(size_t) == sizeof(void*). When C was growing up, there were many architectures about. It only started with the PDP-11.

There are two compatibility issues here: hooks and assembly. They are complaining about JNI issues. These are mostly just translation concerns in the compartmentalization layer. (Performance loss is possible here.) Hooks: Network protocol/proxy is basically the answer. Compatibility issues are usually self inflicted here. One exception is endianness, C and C++ cannot escape this. (Usually JNI hides this as this comes from assembly.) Assembly: C was originally created for abstracting assembly. Many people use C APIs for compatibility from assembly ABI! We are mostly attacking compilers and C extensions here. This argument is outside the original scope of C and we can thank most of modern hardware for that.

Keeping memory layouts forward- and backward-compatible sounds like fun

The problem seems to be that versioning and compatibility aren't represented explicitly in C definitions, but are implied from the field order of structs or type alignment. For a universal base ABI, you'd really want something like protobuf, which has explicit field numbers, a first-class concept of "unknown fields," and a defined, platform-independent serialization. All of the clever workarounds that MS does in the minidump example should really be part of the interface specification language. Also, we got ourselves into trouble by using the same type for "an integer (of some size)," "a pointer," "an offset," "an address," and "an integer that is fast for this CPU." Obviously, it's about 40 years too late to do anything about any of this, but we can shake our fists at the sky.