Posted by stickynotememo 1 day ago
Carpenters, plumbers, masons & electricians work on houses 3-300 yrs old, navigate the range of legacy styles & tech they encounter, and predictably get good outcomes.
Only C has, yet, given use that level of serviceability. C99, baby, why pay more?
When there’s an alternative that can compete with that sort of real-world durability, C will get displaced.
Even the most relevant C compilers are no longer written in C.
Worth to point out that most of the C compilers are also C++ compilers.
So the point is kind of distorted.
LLVM is written in C++, also supports multiple language frontends, one of them happens to be C.
Visual C++, also written in C++, happens to still compile some form of C, and after adding some C11 and C17 support (a few items are still missing in 2026), Microsoft is in no rush to add anything else.
The language that matters is the implementation, otherwise we can also talk about the relevance of PL/I compilers from IBM and Unisys, written in C++.
On the contrary, Lisp outshines C to a large degree here. Success has nothing to do with technical merit (if such a thing even exists), it's not a rational game.
In short: Lisp is semantic and geared towards a living system. The basic REPL is sh + cc + ld + db (and a few others) all in one. It's almost a little mind bending how nice these systems are put together, how cleanly they work. C is like pulling teeth in comparison.
I'm not even a fan of Lisp or sexpr languages. But it's the obvious heavyweight champion of longetivity and ultra-pragmatic service record... Yes, even in the systems domain.
A better example might be Guix, depending how “operating system” is defined.
free_sized
#embed
static_assert
Types for enum
Alignof, alignas, aligned_alloc
_Atomic
- People just stopped caring about operating systems research and systems programming after ~2005. Actual engineering implementations of the concepts largely stopped after the second half of 90s. Most developers moved on to making websites or applications in higher level programming languages.
- C hit a perfect balance of being a small enough language to grok, being indepedent of the system manufacturers, reflecting the computer architecture of 80s, actually small in syntax and code length and quite easy to implement compilers for. This caused lots of legacy software being built into the infrastructure that gave birth to the current contemporary popular OSes and more importantly the infrastructure of the Internet. Add in .com bubbles and other crises, we basically have/had zero economic incentive to replace those systems.
- Culture changed. We cared more about stability, repairability and reusability. Computers were expensive. So are programmers and software. Now computers are cheap. Our culture is more consumerist than ever. The mentality of "move fast and break things" permeated so well with economic policy and the zeitgeist. With AI it will get worse. So trying to make a real alternative to C (as a generic low level OS protocol) has reduced cultural value / optics. It doesn't fill the CVs as well.
It doesn't mean that people haven't tried or even succeeded. Android was successful in multiple fronts in replacing C. Its "intents" and low level interface description language for hardware interfaces are great replacement for C ABI. Windows' COM is also a good replacement that gets rid of language dependence. There are still newer OSes try like Redox or Fuchsia.
Unfortunately I think Don Box’s was the only person in the world who really understood it all.
Using it from MFC, kind of alright.
Using it from .NET, depends if Framework, .NET Native, or modern, with various levels of usability.
Using it from ATL, WRL, C++/WinRT, is a mess unfortunely.
and so it was that after that date, all development of
embedded systems
kernel drivers
digital audio workstations
video editors
codecs for audio and video
anything that involved actually controlling non-computer hardware
game engines
It is better and higher performing hardware but until Rust and Zig arrived, the most popular ways of designing system-level software stayed the same. RTOSes work the same as how they work in late 90s / early 00s. C ABI is still the majority of communication interface. Interacting with OS using system calls stayed the same. After virtual memory and paging no big change in OS design happened. Main programming design patterns in C and C++ also stayed the same.
One area that stayed interesting is GPU programming. Nowadays CPUs basically provide us a PDP-11 simulator. Most of the time you don't need to recompile programs to harness most of the gains from a CPU. GPUs expose more of their internal hardware detaila than CPUs and unlike CPUs you need to recompile programs (which is what a GPU userspace driver does) to use newer models.
"Designing (New) C++ Hardware" - https://www.youtube.com/watch?v=86seb-iZCnI
And now with tiled architecture, Python JIT as well.
I am not sure I buy this from a system perspective, especially when taking this[1] into consideration.
______
1. Alexis King's reply to "Why do common Rust packages depend on C code?". Link: https://langdev.stackexchange.com/a/3237
It cares about calling conventions and what you can store in registers vs what you cannot. There are multiple possible ways of doing an RPC call and C ABI only provides one way of doing it.
Now you can move the goal posts and assert that any data serialized into a memory buffer is an array of ints.
There was no Rust at that point, and I used the most basic tool that could do it.
Could I have done this in Java with gymnastics of JNI, linking C into the JRE?
Definite maybe.
Unless one is stuck with Android Java, Google's J++.
IMO I do see this changing in the future as higher power computers become expensive once again, and I'm not just referring to the recent chip shortage.
I could write a whole essay about why, but now isn’t the time. I’m just going to enjoy the fact that TFA and the author don’t get it.
Is there an answer here more interesting than "it's what Unix and Windows were written in, so that's how programs talked to the OS, and once you have an interface, it's impossible to change"?
> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...
Pity that in regards to secure programing practices in C, community also ignores the decisions of the authors.
> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.
Also to be noted that on Plan 9 they attempted to replace C with Alef for userspace, and while the experiment failed, they went with Limbo on Inferno, and also contributed to Go.
And that C compiler on Plan 9 is its own thing,
> The compiler implements ANSI C with some restrictions and extensions [ANSI90]. Most of the restrictions are due to personal preference, while most of the extensions were to help in the implementation of Plan 9. There are other departures from the standard, particularly in the libraries, that are beyond the scope of this paper.
C is a pretty OK language for writing an OS in the 70s. UNIX got popular for reasons I think largely orthogonal to being written in C. UNIX was one of the first operating systems that was widely licensed to universities. Students were obliged to learn C to work with it.
If the Macintosh OS had come out first and taken over the world, we'd probably all be programming in Object Pascal.
When everyone wanted to program for the web, we all learned JavaScript regardless of its merits or lack thereof.
I don't think there's much very interesting about C beyond the fact that it rode a platform's coattails to popularity. If there is something interesting about it that I'm missing, I'd definitely like to know.
As if you could separate Unix from C. Without C there wouldn't have been any Unix to become popular, there wouldn't have been any coattails to ride.
C gave Unix some advantages that other operating systems of the 1970s and 80s didn't have:
Unix was ported to many different computers spanning a large range of cost and size, from microcomputers to mainframes.
In Unix both the operating system and the applications were written in the same language.
The original Unix and C developers wrote persuasive books that taught the C language and demonstrated how to do systems programming and application programming in C on Unix.
Unix wasn't the first operating system to be written in a high-level language. The Burroughs OS was written in Algol, Multics was written in PL/I, and much of VMS was written in BLISS. None of those languages became popular.
IN the 1970s and 80s, Unix wasn't universal in universities. Other operating systems were also widely used: Tenex, TOPS-10, and TOPS-20 on DEC-10s and 20s, VMS on VAXes. But their systems languages and programming cultures did not catch on in the same way as C and Unix.
The original Macintosh OS of the 1980s was no competitor to Unix. It was a single user system without integrated network support. Apple replaced the original Macintosh OS with a system based on a Unix.
Of course, they weren't available as free beer with source tapes.
> Apple replaced the original Macintosh OS with a system based on a Unix.
Only because they decided to buy NeXT instead of Be.
Had they bough Be, that would not been true at all.
I think this was less important then, than people sometimes think.
I recall those days. In the 1980s and 90s I worked as a scientific programmer in a university department. Some of our software was commercialized and sold and supported as a product for a time in the 80s. Pardon the following long memoir, but I think some reporting on what actually happened then, as seen by even one participant, is pertinent.
We used a VAX with DEC's VMS operating system. Our application was developed in DEC Pascal (which didn't have the limitations of Standard Pascal because it used the DEC CLR, Common Language Runtime). Later on we began using Allegro Common Lisp for some things.
Through the 80s and early 90s, we never used Unix and C. And, we were not unusual, even in a university. Most of the VAXes at that university ran VMS (or one of the DEC-10/20 OS in the early 80s), including the computer science department (which began running Unix on some but not all systems later in the 80s). So Unix was not as pervasive in the 80s as some people seem to think.
About "free beer": running Unix on a VAX in the 1980s was definitely not "free", it was a major investment in time, effort, and yes, money (in the form of salaries). First, the OS wasn't a separate line item. You bought a bundled system including both the VAX hardware and the VMS OS. Then the DEC guy came and turned it on and it just worked. I don't even know how buying a bare VAX and installing your own OS worked. How did you handle DEC field service? They required their own utilities that ran on VMS. If you used Unix, you needed an expert in Unix to install it and maintain it.
And it was no different with the early commercial Unixes. You bought a Sun workstation and it came with their Unix bundled (Solaris or whatever). In the 1990s we switched from VAX/VMS to HP workstations that bundled HP-UX, their Unix. In all of these Unix platforms, Unix was bundled and you did pay for it, it was just included in the price.
I think there is some confusion about the history. The free, frictionless, install-it-and-run-it-yourself OS was not Unix in the 80s, it was Linux in the 1990s. By then C and Unix-like operating systems were well established.
Also, there was genuine admiration for Unix technical features, notably its simplicity and uniformity, even at sites like ours that didn't use it. There were several projects to give VMS a Unix-like userspace. There was a (yes) free Software Tools project (that was its name), and a commercial product called Eunice. People who had already paid for VMS paid more for Enunice to make VMS look like Unix.
Unix was a better platform for teaching CS than VMS or the other alternatives.
VMS did come with source code. It came on a huge stack of fiche cards, along with several pallet-loads of hardcopy documentation in binders.
There was nothing like the books The C Programming Language by K&R, or The Unix Programming Environment by Kernighan and Pike. Or the many Unix and C books that followed them. And then the college courses that used them.
Instead there were special courses in system programming and OS internals (separate courses) from DEC. The university would pay for them once in a while. A DEC expert would come for a week and programmers from all the VAX sites would get together all day every day in a classroom while they lectured. There was no textbook, but everyone got a huge binder of printed notes.
So systems programming on VMS, and I suppose other non-Unix platforms, remained an esoteric, inaccessible art, totally divorced from application programming, that used a programming language that was not used for anything else.
A few words comparing my experience programming in C in the 1990s to programming in DEC Pascal in the 80s: C wasn't much worse. The greater safety of Pascal did not make much difference in application programming. In Pascal, array-bounds errors etc. produced a crash with a traceback. In C similar errors produced a crash with a cryptic message like "segfault". But often the actual defect was far from the line that crashed, that appeared in the traceback, so the investigation and debugging was similar in both languages. But the more common (and often more difficult) errors that just computed the wrong answer were about the same in both languages.
Then the students needed access to lex/yacc etc for their courses and X Windows too.
That we produced other Unix programs was just an artifact of the original drive to have Unix. The Compaq 386 or Macintosh II were niche products for that job and VMS had been turfed by the late eighties.
To me it looks like there is a better way to do things and the better one eventually wins.
From page 52:
> Operating systems have to deal with some very unusual objects and events: interrupts; memory maps; apparent locations in memory that really represent devices, hardware traps and faults; and I/O controllers. It is unlikely that even a low-level model can adequately support all of these notions or new ones that come along in the future. So a key idea in C is that the language model be flexible; with escape hatches to allow the programmer to do the right thing, even if the language designer didn't think of it first.
This. This is the difference between C and Pascal. This is why C won and Pascal lost - because Pascal prohibited everything but what Wirth thought should be allowed, and Wirth had far too limited a vision of what people might need to do. Ritchie, in contrast, knew he wasn't smart enough to play that game, so he didn't try. As a result, in practice C was considerably more usable than Pascal. The closer you were to the metal, the greater C's advantage. And in those days, you were often pretty close to the metal...
Later, on page 60:
> Much of the C model relies on the programmer always being right, so the task of the language is to make it easy what is necessary... The converse model, which is the basis of Pascal and Ada, is that the programmer is often wrong, so the language should make it hard to say anything incorrect... Finally, the large amount of freedom provided in the language means that you can make truly spectacular errors, far exceeding the relatively trivial difficulties you encounter misusing, say, BASIC.
Also true. And it is true that the "Pascal model" of the programmer has quite a bit of truth to it. But programmers collectively chose freedom over restrictions, even restrictions that were intended to be for their own good.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
In my opinion it is only Rust that offers a language without runtime system requirement and fixes essentially all of the problems of C.
C has a runtime, even if tiny. That is what calls into main(), handles floating point arithmetic when none is available, functions that run before and after main(), nowadays also does threading.
Heap memory handling in Pascal, Modula-2, Ada, is much safer than C, first of all no need to do math to calculate the right size, arenas are available on the standard library, dinamic allocation can also be managed by the compiler if desired (Ada), pointers are safe as they by default must be used with existing data, however if one really wants to do pointer arithmetic it is available.
The only issue that they have in regards to C, is the use-after-free, but that apparently isn't an issue for folks moving away from C into Zig, wich is basically Modula-2 with some C syntax flavour.
There is a quite a bit of C code that makes creative use of the size of allocations. For example linked lists with a variable sized payload. Again one of the things that would prevent a C programmer from switching to Pascal.
I don't expect the Zig user base to become larger than the Rust user base any time soon. But we have to wait and see, Zig is quite young.
Creative use of the size of allocations are also possible in those languages, the BIG difference is that they aren't the default way everything gets done.
(I know quite well that C couldn't. Even a C++ vector may or may not, depending on which access method you use.)
I mean Unix had to be written in C, not in, say, Algol or PL/I or BLISS, high-level languages used to write other operating systems.
I also meant that the features of C were not put there by impulse or whim, they were the outcome of considered decisions guided by the specific needs of Unix.
> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.
1. Conservation of mass: the amount of C code you put in will be pretty close to the amount of machine code you get out. Aside from the preprocessor, which is very obviously expanding macros, there are almost no features of C that will take a small amount of code and expand it to a large amount of output. This makes some things annoyingly verbose to code in C (eg. string manipulation), but that annoyance is reflecting a true fact of machine code, which is that it cannot handle strings very easily.
2. Conservation of energy: the only work that will be performed is the code that you put into your program. There is no "supervisor" performing work on the side (garbage collection, stack checking, context switching), on your behalf. From a practical perspective, this means that the machine code produced by a C compiler is standalone, and can be called from any runtime without needing a special environment to be set up. This is what makes C such a good language for implementing garbage collection, stack checking, context switching, etc.
There are some exceptions to both of these principles. Auto-vectorizing compilers can produce large amounts of output from small amounts of input. Some C compilers do support stack checking (eg. `-fstack-check`). Some implementations of C will perform garbage collection (eg. Boehm, Fil-C). For dynamically linked executables, the PLT stubs will perform hash table lookups the first time you call a function. The point is that C makes it very possible to avoid all of these things, which has made it a great technology for programming close to the machine.
Some languages excel at one but not the other. Byte-code oriented languages generally do well at (1): for example, Java .class files are usually pretty lean, as the byte-code semantics are pretty close to the Java langauge. Go is also pretty good at (1). Languages like C++ or Rust are generally good at (2), but have much larger binaries on average than C thanks to generics, exceptions/panics, and other features. C is one of the few languages I've seen that does both (1) and (2) well.
Take the "wobbly types" for example. It would have been more "minimal" to have types tied directly to their sizes instead of having short, int, long, etc.
There isn't any reason that compilers on the same platform have to disagree on the layout of the same basic type, but they do.
The complaints about parsing header files could potentially be solved by an IDL that could compile to c header files and ffi definitions for other languages. It could even be a subset of c that is easier to parse. But nothing like that has ever caught on.
This hasn't been true for decades. x86 assembly is now itself an abstraction over what the CPU is actually doing.
Microcode, speculative execution, etc.
For example, C has pointer provenance, so pointers arent just addresses. Thats why type punning is such a mess. If a lang claims to be super close to the hardware this seems like a very weird thing.
What makes C feel free for programming is that instead of prescribing an implementation paradigm, it instead exposes a computing model and then lets the programmer write whatever is possible with that (and also what is not -- UB). And a lot of higher level abstractions are quickly implemented in C, e.g. inheritance and polymorphism, but then they still allow to be used in ways you like, so you can not just do pure class inheritance, but get creative with a vtable, or just use another vtable with the same object. These are things you can't do when the classes are a language construct.
My gripe is only with people acting like the C abstract machine doesn't exist and C is just syntax sugar for a bit of assembly. It's a bit more involved than that.
Exactly.
Everything in assembly is still one-to-one in terms of functional/stateful behavior to actual execution. Runtime hardware optimization (pinhole instruction decomposition and reordering, speculative branching, automated caching, etc.) give a performance boost but do not change the model. Doing so would mean it didn't work!
And C is still very close to the assembly, in terms of basic operations. Even if a compiler is able to map the same C operations to different instructions (i.e. regular, SIMD, etc.)
If language extensions to ISO C are allowed, then same goes for my selection on competing systems languages.
Java with only primitive values, arrays, and classes only with fields and static methods.
But that wouldn’t be idiomatic Java, so typically non-explicit abstractions such as polymorphism have code generated for them that you don’t have explicit control over.
C is consistently low level because that’s all you get. Down to direct access to addressing and RAM, the stack frame, etc. as with assembly.
Being idiomatic or not doesn't matter, what counts are what language features are available.
Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.)
And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it.
And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge.
In terms of non-bijectivity, for systems programming and performance choices C makes it easy to drop into assembly. But the former are uniquely application specific. And the latter doesn’t make the C version less like the assembly it maps onto - whether the compiler uses the more performant instructions for the context or not.
C’s convenient assembly inlining, and the handoff in both directions being smoothed by an assembly friendly model of the C code around it, are both a part of the “closeness”
But C is generally “close” to assembly, because its data types emphasize types handled natively, compound types reflect RAM layout, and pointers are explicit addresses to data and code. And those address values can be constructed and operated on just like any other data.
C is objectively closer to assembly than languages with strongly required abstractions. (E.g., Java classes, Lisp S-exp's/cons cells, etc.)
C is more “strictly closer” to assembly than languages with more optional abstractions, even if they also allow for relatively low level coding.
Functions could be viewed as a preferred abstraction, but they have a clear assembly level model accessible directly with pointer arithmetic. And they don’t get in the way of directly encoding custom argument passing schemes, and using goto’s and zero argument functions and tail calls as atomic assembly calls for function and jumps for continuations.
Types are a significant non-assembly abstraction, but are zero-cost in that they don't separate C from assembly, but C from C, as a code safety mechanism that is easily escaped.
It is often easy to add abstractions, via regular C, or macros, but you have to provide an explicit implementation for them in the source or complied library.
(However, if macros, with their mixed logical, symbol, text and file “data” model, are viewed as C source instead of as a C source construction language, then C becomes a very wacky abstraction language with behavior and rules that look nothing like simple assembly.)
The manipulation of memory by C programs is close semantically to the manipulation of memory by assembly programs. Memory accessed through pointers is similarly "external" to both assembly language and C programs.
The evaluation of C program code is not close to assembly language. C programs cannot reflect on themselves portably; features like parameter passing, returning, and allocating local storage during procedure activation, are not in the programming model.
C loses access to detailed machine state. Errors that machine language can catch, like overflows, division by zero and whatnot, are "undefined behavior". An assembly language program can easily add two integers together and then two more integers which include the carry out from the previous addition. Not so in C.
Assembly language instruction set designs (with some exceptions) tend to bend over backwards to preserve the functioning of existing binary programs, by maintaining the illusion that instructions are executed in sequence as if there were no pipelining or speculative execution, or register renaming, etc.
Meanwhile, C compiler vendors bend over backwards to prove that code you wrote 17 years ago was wrong and make it fail. C is full of unspecified evaluation orders and various kinds of undefined behavior in just the basic evaluation model of its syntactic, built-in constructs; and then some more in the use of libraries.
In assembly language, you would never have doubt about the order of evaluation of arguments for a procedure.
Even when it comes to memory, where C and asasembly language agree in many points, there are some subtle ways C can screw you. In assembly language, you would never wonder whether copying a structure from one memory location to another included the alignment padding bits. In C you also don't have to wonder, if you use memcpy. Oh, but if you use memset to clear some memory which you don't touch afterward and which goes out of scope, the compiler can optimize that away, oops!
Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C.
The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they are even closer since they got more features builtins that modern assembly can now do that was not part of the design in C. (SIMD, threading, ...)
Modern languages also have extra abstractions that makes programming easier without compromising on the cost. There are more abstractions than in C, but they also are optional. (Just like you could use goto instead of while or for loop, but you're happy this abstractions exist. We could also use functions pointer in C++ instead of virtual functions, but why would we if the language provide tools that make programming easier, for the same result)
It's 2026, to this date I cannot use standard library/api, to open a file with utf-8 filename without a null terminating string.
When you want to talk to the OS you constantly face the need to had unnecessary overhead (allocation due to string convertion, strlen).
The OS itself does not prevent anything from having those standard "no overhead" API.
However, it's pretty clear that nobody cares to define some new sane interface and nobody care to deprecate old ones.
That would include both API and ABI.
And then the gain is close to zero because most filenames are short enough that there is almost no gain.
You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first.
Every single piece of software that need to interact with the file system needs to deal with this.
I'm not asking about a new string type. I'm asking to be able to be free from null terminating string.
You only need to provide a length.
Not everything has to be written with all the warmth and humanity of a UN subcommittee interim report on widget standardisation.
Choose your own adjective
- unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning.
- aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword.
There are more but I understand the logic/usability/history behind them. The above points should have been addressed in the 80’s.
As you said, it's easy to see where it came from, but it should've been fixed long ago.
Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...
C is sin incarnated.
> The barebones-macro-system?
The CPP is a different language and designed that way so you can use another language that suits you better, most don't do that, because the default is fine.
You simply choose the integer type that your problem or task requires. If the hardware genuinely can‘t cope with it (performance), you reevaluate your requirements, define new constraints and choose new types. This is basic requirements engineering, which C only made more convoluted.
I strongly disagree. The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. Does this variable represent the size of an object, an address, a difference or just a random positive integer? Then use size_t, uintptr_t, ptrdiff_t and unsigned int respectively. Why should I care what exact sizes these are? I hate that modern (system) languages completely throw away that concept. "I want a unsigned integer" "oh, you mean u32" "No! I really mean an unsigned integer."
Also when I do want e.g. 32 bit available, there is no reason, I need to use a suboptimal 32 bit wrapping behaviour when I don't need it. The correct type to use for computation for that would be uint32_fast_t and the implementation chooses what makes sense to use for this.
Choosing the right type is a function of signedness, upper/lower bound (number of things), and sometimes alignment. These are fundamental properties of the problem domain. Guesstimating is simply not doing the required work.
If you target about 32bit and 16bit, you either think about and using long (on 16 bit is more costly) or you just count seconds.. Or ticks.. or whatever you need.
It's understandable how we got here, but it's an entirely legitimate question - could things be better if we had an explicitly designed interoperability interface? Given my experiences with cgo, I'd be pretty solidly on the "Fuck yes" side of things.
(Of course, any such interface would probably end up being designed by committee and end up embodying chunks of ALGOL ABI or something instead, so this may not be the worst possible world but that doesn't mean we have to like it)
[1] I absolutely buy the argument that HTTP probably wins out for out of process
Also, if I remember correctly, the first Rust and Go compilers were written in C.
Usually it helps to know why some decision was taken, it isn't always because of the technology alone.
Sure history is great and all, but in C it's hard to say reliably define this int is 64-bit wide, because of the wobbly type system. Plus, the whole historical baggage of not having 128-bit wide ints. Or sane strings (not null terminated).
That isn't really a problem any more (since c99). You can define it as uint64_t.
But we have a ton of existing APIs that are defined using the wobbly types, so we're kind of stuck with it. And even new APIs use the wobbly types because the author didn't use that for whatever reason.
But that is far from the only issue.
128 bit ints is definitely a problem though, you don't even get agreement between different compilers on the same os on the same hardware.
It kinda is. Because it was made in the 1970s, and it shows (cough null-terminated strings uncough).
Or you know having a 64-bit wide integer. Reliably.
You did read the article, right?
Yes, we could define a language-agnostic binary interoperability standard with it's own interface definition language, or IDL. Maybe call it something neutral like the component object model, or just COM[1]. :)
It’s not just C. There are a lot of things that could be substantially better in an OS than Linux, for example, or in client-server software and UI frameworks than the web stack. It nevertheless is quite unrealistic to ditch Linux or the web stack for something else. You have to work with what’s there.
Verilog is loosely based on C. Most designs are done in Verilog.
Other than that, Nokia until Microsoft placed an agent on it, Phillips that contributed to CDs, ASML...
There's an argument for full type info at an API, but that gets complicated across languages. Things that do that degenerate into CORBA. Size info, though, is meaningful at the machine level, and ought to be there.
Apple originally had Pascal APIs for the Mac, which did carry along size info. But they caved and went with C APIs.
There has to be an ABI that has to be agreed upon by everyone. Otherwise there wouldn’t be any interoperability. And if we didn’t have the SystemV ABI — what would we use instead? Prepare for a long debate as every language author, operating system designer, and platform under the sun argues for their respective demands and proposals. And as sure as the sun rises in the East someone, somewhere, would write an article such as this one decrying that blessed ABI.
SystemV shouldn’t be the be all and end all, IMO. But progress should be incremental. Because a lingua franca loses its primary feature and utility when we all return to our own fiefdoms and stop talking to one another in the common tongue.
It’s a pain in the metaphorical butt. But it’s better, IMO, than the alternatives. It’s kind of neat that SystemV works so well let alone at all.
Good read though. Thinking about C as not just a language but also a protocol is a different perspective that is useful for the mental model.
The System V ABI is as close as we get to an actual specification but not everyone uses it and in any case it only covers a small part of the protocol.
> I’m trying to materially improve the conditions of using literally any language other than C.
The whole world shouldn't "need to be fixed" because you won't spend the time to learn something.
Rust doesn't even have a stable Internal ABI that's why you have to re-compile everything all the time.