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."

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

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).

To C, or not to C.

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

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

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

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

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.

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

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.

"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 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...

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

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

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.)

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.

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.

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.

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...

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

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.

C is love, c is life and also goddamn nice

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

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..

I don’t C any problems here

No more netflix = no more hoodie?

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

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.

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

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!" 🤣

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?

C MENTIONED LETS GO

How long is an unsigned shlong?

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

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.

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

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.

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

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)

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.

AI = Productivity goes up, quality goes down

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.

12:50 I dont know what zig people has told you to believe that zig is literally a fully fledged C compiler but its literally just clang with additional flags 😅

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 love C in the morning.

Fushcia is the only modern OS that doesn't rely on C lib. It uses it as shim for programs that rely on c lib but it's not required. It uses language agnostic Fuchsia Interface Definition Language (FIDL) to describe binary interface.

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

C is the means by which all is revealed.

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.

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.

C (and sometime C++) is the lingua franca of embedded systems. Of all the dozens of embedded processor in your computer right now, most of them are written in C. (flash management processor, hard disk drive processor, PCIe PHY controller, touch panel processor, etc , device drivers.. to name just a few)

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

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.

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

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.

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.

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.

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.

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.

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.

Still a language, but also a protocol.

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

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.

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.

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

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

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."

Can't we all just get a long?

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

I find it hilarious how much rust fanbois complain about C abis and apis, while rust in itself is an unstable, constantly breaking mess.

error: ‘long long long’ is too long for GCC

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

Terrible: that’s the long and short of it

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.

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.

Confusing article that makes almost no sense at all, even if the author had the right ideas, clearly couldn't express them. This could be explained in less than 5 minutes by Casey :shrug:

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

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.

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

Very interesting article but I really didn't like the tone. It felt very high-horse and dismissive even where it wasn't

not a language anymore ≠ not just a language anymore. this is not a comment anymore

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

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.

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

LOL C is not a programming language? I guess I have been wrong since 1974 oh well...

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.

As soon as I started seeing the extend struct code I knew this was familiar. Migrating from dx11 to dx12 was fun with all the dxgifactory versions

Last I tried, not long ago, zig wasn't able to use my favourite C library. So... nope, it's not good enough.

kind of tech debt

Loving the Zig callouts.

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

The author is confusing C ABI, a protocol with C the programming language. Maybe its just clickbait but that part of the argument was nonsense

Megumi Fushiguro : "I just learned C" >>C is not a language anymore Megumi Fushiguro. :" With this treasure I summon. . . ."

I can't wait to finally understand half of what this video showed 15 years later.

C_ode C_oding C_ompiler C_omputer