dzaima

65 ms·

871.
by dzaima 5y ago
huh, I guess that's still not hard-coded. But a non-8-bit-byte system probably runs near nothing to interface with anyway, and would definitely need a completely separate ABI in any scenario.
872.
by dzaima 5y ago
C definitely doesn't provide a well-defined stable interface. Specific ABI definitions might, but there are 176 of those, and implementing all of those in another language is decidedly not what I'd call "easy".
873.
by dzaima 5y ago
i mean, if sizeof(int8_t) varied, noone would even try to use C as a lingua franca. I, as the programmer, would never expose unknown width integer types, but other things still will, and I'll be forced to interact with them. Allowing s
874.
by dzaima 5y ago
Does fortran use syscalls on BSD, macOS, Android, iOS, and Windows too? But, again, the OS isn't even the main problem. There are many orders of magnitudes more libraries that use the C ABI as their interface than what OSes provide thr
875.
by dzaima 5y ago
see my edit - the ARMv8 ABI even specifies x18 to be possibly platform-defined. So those aren't unreasonable, and I'm probably overestimating how many things misuse it. But apparently that list includes GNU MP[0], and it's ea
876.
by dzaima 5y ago
Architectures do differ, but there's really not a good reason to have dozens of ABIs per architecture. But that's what we have - 15 for aarch64, 9 for armv7, 27 for x86-64, etc. Most things in each set most likely do match, but th
877.
by dzaima 5y ago
Not just Rust, but every language will need to interface with C sooner or later. And not just to the OS, but to the window manager, graphics APIs, libraries (ffmpeg etc). So, unless you think that C is the perfect language for doing liter
878.
by dzaima 5y ago
I'm not saying all would follow it, but at least they'd have to try to, or risk being poorly supported (unless they're already at the top of the food chain, but then they'd already just be the ones dictating new ABI stan
879.
by dzaima 5y ago
I mean, yes, right now, it has ±0 chance to become a thing. Still doesn't make status quo any better, and does not at all change that such a universal ABI probably could be much better.
880.
by dzaima 5y ago
Well, it so happens that C23 has so far been decided to remove K&R function declarations! (the "int fn() int arg1, arg2; { /*code*/ }" kind) So it's not utterly impossible for old things to get removed (though w
881.
by dzaima 5y ago
I don't think the author blames it on C. C didn't choose to become the ABI of 99% of the world. But yet, it is. > You have to speak the C ABI to talk to the OS [...] What is your alternative that doesn't involve a common A
882.
by dzaima 5y ago
Between architectures you'd indeed need quite a few differences, but for the same architecture it'd be nice if things more or less agreed on things. Specifically, I think it'd be very reasonable & possible to have an ABI
883.
by dzaima 5y ago
C itself doesn't, but the OS deciding how it interfaces with C quickly results in all C programs for that OS doing the same thing, and, since C is the lingua franca of programming languages, in every single program with a cross-languag
884.
by dzaima 5y ago
I'd argue it's more like only 40% of the way to a proper ABI; sizeof(long) varying on the same CPU architecture is just horrible. Sure, it wasn't meant to be an ABI, but, well, it is. And we're stuck with it. And oh how
885.
by dzaima 5y ago
It not being possible to improve the situation doesn't mean that the current situation is good. Is the article's rant gonna achieve much? Most likely, nope. I'm fairly sure the author recognizes that.
886.
by dzaima 5y ago
A lisp machine, by definition, runs lisp. The ABI problem only exists in environments where multiple programming languages exist. I doubt much non-.NET software runs on that C# OS either. If you want multiple programming languages to be abl
887.
by dzaima 5y ago
You'd obviously prefer calling into things made in your own language than some other. But, from any other language you'd much prefer a C interface over having to explicitly describe which registers & stack slots to put things
888.
by dzaima 5y ago
Yes, it is possible to make worse ABIs than C's. That's not a surprise. Doesn't mean C's is automagically the best possible. Something that, at the very least, doesn't have varying sizes for the same type between ar
889.
by dzaima 5y ago
Except that C defines the way nearly everything everywhere passes function parameters over registers. Not C's fault, but still a thing affecting everyone that doesn't write C, as C doesn't even try to be a good ABI, because i
890.
by dzaima 5y ago
Again, there's more than the OS kernel that a programming language will need to interact with. You don't go through syscalls to make an X11 window or read keyboard/mouse inputs or draw graphics. There are thousands of utiliti
891.
by dzaima 5y ago
I mean, a C interface is better than a machine code interface. The problem with that is that, unless you include a C compiler (or at least a thing that understands the 176 C ABIs) with your language, you can't use it. (not that machine
892.
by dzaima 5y ago
A lot of the comments here are saying that C not having a well-defined ABI is acceptable/good. For people writing C, yes, that may very well be a good thing. But as the article states, pretty much every single language must interface w
893.
by dzaima 5y ago
It's less that the OS is written in C, but more that literally every single interface to literally anything is either written in C, or isn't meant to be used by multiple languages. C is the de facto standard for interacting with
894.
by dzaima 5y ago
I've experienced Cinnamon on Linux Mint crashing (leaving the display frozen), but it was possible to go do a tty with ctrl+alt+functionkey (each of f1-f6 goes to a different tty, f7 goes back to the display) and manually restart it. B
895.
by dzaima 5y ago
having a "bigintmax_t" would...... work, but it's absolutely horrible and defeats the purpose of intmax_t being.. um.. the maximum integer type. A struct of two integers couldn't be used in regular & bitwise arithmet
896.
by dzaima 5y ago
The problem is that, as-is, there's no way to add a 128-bit integer type (which'd be very uselful!!) to the C standard (among other things like time_t or something), because that'd require changing intmax_t to 128-bit, and th
897.
by dzaima 5y ago
as far as I understand, the kernel uses C89 + GNU extensions, cause there definitely are usages in the kernel of it. (my searching showed it being only used for defining globals, which is a weird standard, but I don't see anything prev
898.
by dzaima 5y ago
The question of safety is often much more about coding standards than actual language features. For a kernel, you'd be violating Rust's safety features left right and center (or have a slow kernel that just dies on OOM; choose one
899.
by dzaima 5y ago
you can assign a new object into *buf in C just fine, with "*buf = (struct YourType){.prop1 = a, .prop2 = b}"; it even zero-initializes unset fields! So C and Rust give you precisely the same abilities here. edit: the "struct
900.
by dzaima 5y ago
And knowing which one it is will probably influence which one it should be, in a halting-problem-esque way.

More ›