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

@usmanmehmood55

Ай бұрын

We all have "dyslexic man that quit his job to read articles to us while we drive to work"-itis

@usmanmehmood55

Ай бұрын

Either that or ligma.

@DeusEx3

Ай бұрын

@@usmanmehmood55 what's ligma?

@usmanmehmood55

Ай бұрын

​@@DeusEx3ligmaclang

@pixelcatcher123

Ай бұрын

ligma nutz

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

@skhotzim_bacon

Ай бұрын

Such a shame. We need to bring back humor and easter eggs

@Sven-W

Ай бұрын

And long long is two long :^)

@skhotzim_bacon

Ай бұрын

@@Sven-W Long long long long would be two too long :^)

@BruceHoult

Ай бұрын

That one is, sadly, not from MPW C.

@SpocksBro

5 күн бұрын

C love you long^2 time max

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

@amj864

Ай бұрын

yes, skill issues in C lead to programming in rust.

@VivekYadav-ds8oz

Ай бұрын

C is a mindset. C is a grindset.

@Seven-ez5ux

Ай бұрын

- said no one, ever

@ScottLovenberg

Ай бұрын

Rawdogging bits 4 lyfe, Bois!

@rationalagent6927

Ай бұрын

Like putting a label on a lifestyle. So they can water it down

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

@profilore

Ай бұрын

Why do i love this comment, i must have clang for brains

@____uncompetative

Ай бұрын

Bjarne Stroustrup should have called it C-- as it yields C and then by the subsequent sequence point every new feature makes it worse.

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

@macchiato_1881

11 күн бұрын

And their love child is a horribly disfigured abomination. The analogy holds well.

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

@Waine2000

Ай бұрын

So true, this is the reason for so much different ISAs and even different architectures, such as GPUs ou DSPs, using C language most of the time. They can use C programming model and adapat it to the ISA/model specifics.

@vonnikon

Ай бұрын

Good luck running all those modern languages on a DSP with 40bit integer and 16bit char. C can handle it beautifully. It is not C which has a problem. The problem is the false hardware assumptions in the other languages.

@gagagero

Ай бұрын

​@@vonnikonThe problem is that the author fundamentally doesn't understand ABIs.

@WHYUNODYLAN

Ай бұрын

NO! This is a complete misunderstanding. It takes an immense amount of backend compiler work to support even a single target, and this isn't made easier by C's type system since the stdint types still have to be supported. The ideal, rewrite history scenario is 1) C's types always functioned like stdint types and 2) compiler authors didn't name targets the same thing if they had different ABIs.

@zaper2904

Ай бұрын

@@WHYUNODYLAN It's not easier *today* when all architectures work in a broadly similar way there is a reason the original type sizes in C were implementation defined and that's because you could have an old supercomputer from the 70s that only worked with 24 bit words as its smallest addressable memory unit and you needed to support that.

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

@Asto508

Ай бұрын

Ugly malformed shoulders

@macchiato_1881

11 күн бұрын

Probably at least an intmax_t amount of shoulders.

To C, or not to C.

@blobglo

Ай бұрын

we should C# 😔

@juanmacias5922

Ай бұрын

@@blobglo I just barfed in my mouth, a bit.

@Jetsetbob3

Ай бұрын

"C? Why not A?" Asian dad.

@thingsiplay

Ай бұрын

I C what you did there.

@gcxs

Ай бұрын

to C is to believe

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

@nordgaren2358

Ай бұрын

This has been coming up a lot recently. :(

@zaper2904

Ай бұрын

​​@@nordgaren2358Wow it's almost like systems programmers have been telling rustaceans for years that they need to have a stable ABI ...

@platin2148

Ай бұрын

Because it has only one implementation and that one is not good. And as it has only one it can destroy abi easily.

@nordgaren2358

Ай бұрын

@@platin2148 Rust doesn't have an ABI.

@kippers12isOG

Ай бұрын

Every binary you can interface with has an ABI. I think you mean that it doesn't have a defined or stable ABI

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.

@eightsprites

Ай бұрын

Not only as a newbie.. It gives you so much understanding of how computers work its silly.

@JerehmiaBoaz

Ай бұрын

Yeah, it makes you wonder why the geniuses who knew the hardware intimately by writing assembly all day were desperate for high-level languages with lots of high-order abstractions, doesn't it?

@jnharton

Ай бұрын

@@JerehmiaBoaz They probably weren't actually desperate for "high-level languages with lots of high-order abstractions". It's more likely that someone else wanted them, so they begrudgingly created them.

@AntsanParcher

15 күн бұрын

That's a trap. C is very far from the metal in very important respects and if you think that it works like the hardware below it does, you're in for some really nasty surprises. You expect an integer overflow to result in a wraparound? That's not in the spec, and a lot of compiler optimizations will actually show you that C does not work like the underlying hardware there. If you wanna know how hardware works, ~~learn~~ write a Forth.

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.

@dixaba

Ай бұрын

Wait, intptr_t is actually defined as using two's complement? While regular numbers are like "Ehh, we don't know what we want and what we are, we just exist"?

@irnehhenri

Ай бұрын

​@@dixaba C23 finally requires two's complement representation for all signed integers, idk about intptr_t in the old standards tho

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

@juanmacias5922

Ай бұрын

Mother ship.

@Leonhart_93

Ай бұрын

The thing that I don't get is the obsession of making a new language for every single niche task these days. It's a lot like the web dev, "how to lose focus on mastering a single thing". Ideally I want to go back to a standard few powerful languages and just use a well defined lib for a certain task.

@thingsiplay

Ай бұрын

C was great in the past.

@notuxnobux

Ай бұрын

If you create a core library that you want others to use to create programs with and if for example it's a library implementing a new protocol or part of it then it should be written in C. If it isn't then I assume the library isn't a serious project. Core libraries need to be fast, use small amount of memory, not crash on a failure (looking at you rust, with panic on memory allocation failure), be able to use on any system and platform and from any programming language.

@CyberDork34

Ай бұрын

LLVM is part of it. You don't actually have to make a full compiler anymore. You can make a language parser for any syntax, plug the result into an LLVM backend, and claim your new language has "comparable performance to C".

"Nothing better than C" - Linus Torvalds

@thingsiplay

Ай бұрын

This quote and how he is saying it, always pops up in my head. But I think the quote is taken out of context and Linus actually means: "Nothing better than C for Linux Kernel."

@soulextracter

Ай бұрын

@@thingsiplay That is because 90% of people who are quoting it are getting the quote from the same video that's been recommended to everyone and their grandma at this point. I don't even think most people actually watch the video. They just see the title and it sticks.

@rusi6219

Ай бұрын

@@soulextracter it's so annoying along with that atrocious quote by Stroustrup about people complaining about languages (I'm team C)

@poggarzz

Ай бұрын

@@rusi6219 whats the quote?

@rusi6219

Ай бұрын

@@poggarzz something about languages that aren't complained about aren't in use

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.

@plaintext7288

Ай бұрын

What if I'm compiling for some tiny 8/16 bit cpu running Linux?

@amor76

Ай бұрын

​@plaintext7288 you use a uint8_t and uint16_t

@MarekKnapek

Ай бұрын

@@plaintext7288 Linux doesn't support 16bit computers.

@chikinrasshu

Ай бұрын

@@plaintext7288 you can still emulate larger types. (that's how we used 128bit types before)

@turun_ambartanen

Ай бұрын

@@plaintext7288 long is at least 32 bits. Your compiler may throw an error or insert code to do the math for a 32bit number with a 8/16 bit cpu. This will be horribly inefficient, but it will work.

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.

@cat-.-

Ай бұрын

im sure gcc, clang hardcode it already, and by the look of this article so does every other language. (Either that, or they use C). So its just hard code all the way down

@VFPn96kQT

Ай бұрын

You can use FIDL to describe ABI and allow automatic tools to generate required bindings. That's what Fuchsia uses.

@edwardcullen1739

Ай бұрын

Agreed. The author doesn't really understand the distinction between the System Call Interface and the C wrapper library that most people interact with. He does not understand that all C implementations are exactly that and they have freedom to do their own thing. This is not a failure of C or even other languages, it is the nature of the beast and he is simply unaware that people "don't bother" writing their own SysCall wrappers - they just reuse glibc or whatever. The Linux System Call Interface is fixed and Linus does a LOT to ensure it never breaks (the rants he has about this 😅...) There is nothing to stop Rust from implementing a SysCall wrapper library that bypasses glibc. They just haven't done the work.

@gnuemacscoin

Ай бұрын

The article wasn't attacking the idea of a portable binary interface specification language, it was pointing out how insane C must appear to be in fulfilling that role. In web programming there's protobufs, graphql, openapi, none of which demand that you parse an unparseable language if you wish to interact with the system exposing the API.

@cat-.-

Ай бұрын

@@gnuemacscoin interesting. i was wondering what would happen if linux kernel exposed a protobuf api when I saw that linux interface.

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.

@krumbergify

Ай бұрын

Go does this, right?

@retropaganda8442

Ай бұрын

​@@krumbergifyDo a degree, yes, but it's kinda impossible on some platforms where the syscall interface is undocumented or unstable, in which case, it still uses whatever wrapper library exists to make the syscalls.

@phillipsusi1791

Ай бұрын

"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.", no the vast majority of C libraries do far more than just "call the kernel".

@ade5324

Ай бұрын

How about using hardware api's like opengl? i'm pretty sure that all GPU vendors wrote their opengl API implementations for their gpus in C

@edwardcullen1739

Ай бұрын

​@@phillipsusi1791 You're suffering the same lack of understanding that the author of the article does. Whatever standard library has will provide all the same kinds of functionality as glibc, except it relies on glibc to handle syscalls. There is nothing stopping the Rust maintainers from implementing their own SysCall wrappers. Easier on Linux/Unix, not so easy on Windows... But if Rust really is "the future", Microsoft will start to implement a native Rust interface anyway... As to the question of "unstable SysCall interface"... This is answered by Linus MANY "do not break userland" rants; if this is an issue, use a better-managed OS/kernel.

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

@scottfranco1962

Ай бұрын

I build I c header parser a long time ago. The first try was just to recognize keywords and attempt a translation, much like a macro processor. I klash-trashed around with it for some time, and the program got quite large. Finally I decided that it wouldn't work in terms of handing all case, so I realized that the program needed to be the top half of a C compiler with the bottom (actual code generation) chopped off. I rewrote the program as a scanner/preprocessor followed by a syntax follower. That worked much better.

@mgord9518

Ай бұрын

Zig does a lot of things that might as well be magic Macros? Nah, just use the Zig but tell it to do it at compile time Cross compiling? Yes and fuck it, use Zig as a C or C++ cross-compilation toolchain too Build system? Just use Zig for that too, and use it to build anything, including things that aren't even written in Zig Binary size? Smaller than C in most cases Absolute madness.

@ovalteen4404

Ай бұрын

So... the author is crying because it takes more than a couple of lines of code to do that? The typical solution is... a library. Maybe something like llvm.... If you're doing compilery stuff, why complain that you might need to employ a complier library?

@ITR

Ай бұрын

@@ovalteen4404 Because the purpose *isn't* to compile c++. The purpose is to communicate with an ABI.

@ovalteen4404

Ай бұрын

@@ITR But as should have been made painfully clear in this article, communicating with an ABI is NOT a simple thing. You NEED a compiler library to do something like that. And further, the point is that this would be true even if C were NOT the 'de facto' ABI for the system. And libraries like LLVM can do that. You could use it to snarf up a C++ header and then emit code in your own stuff where needed to interact with the interface in that header.

How long is an unsigned shlong?

@chindianajones3742

Ай бұрын

69 inches

@eightsprites

Ай бұрын

a bit longer shlong

@AntsanParcher

15 күн бұрын

Same size as a signed shlong.

@edmunns8825

15 күн бұрын

Anyone who hasn't signed their shlong is untrustworthy.

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

@peppy3519

Ай бұрын

If the ABI is well written, it does not need to talk C but C needs to talk the ABI. The ABI comes before C. C is just a language like any other

@nikolaiartemiev5306

Ай бұрын

Nn

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.

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

@AlFasGD

Ай бұрын

It would be funny if history just repeated itself even after THE big rewrite

@sidma6488

Ай бұрын

never

@moussaadem7933

Ай бұрын

​@AlFasGD i approve of a big rewrite every 64 years

@hardbrocklife

Ай бұрын

Things like extreme archaic ISO standards and all the industrial applications C is used it keep it from evolving.

@tc2241

Ай бұрын

The amount of times I think about this is unhealthy.

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

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

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

@PassifloraCerulea

2 күн бұрын

Hah! I'm sure many of us have had terrible arguments with teachers when we catch them out on their own lack of understanding. I agree that code usually needs to make some assumptions about the ranges of values you can store. It's not usually *dire* because `int` is often big enough and a smaller computer will naturally not be able to work on as large a data set, but you're not wrong. That said, there is some truth to increased portability from "wobbly definitions," but it's more about the language itself. You see, C comes from a time when some major hardware platforms had a 36-bit word size and you couldn't count on a (hardware-supported) 8-bit value or maybe any power-of-2 type size. Two's complement wasn't universal either. If C had demanded exact bit sizes for each type, or two's complement, then no C for you! Computer hardware looks a lot different-and a lot more uniform-50+ years later, and it's easy to forget why certain things don't make as much sense anymore.

@shavais33

2 күн бұрын

@@PassifloraCerulea That, sir, is a very good point! And, gosh, C is still used in all kinds of crazy embedded environments. I feel a bit stupid now. I suppose it does make sense to have a non-specific "int" type, and then have platform-dependent types like "int8" and so on.

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.

@techrev9999

21 күн бұрын

Any language can be compiled to run on any hardware. Just need to have a written compiler. Which is pretty standard. People choose C, because of what it can do - compared to other languages. It's a mid-level language. It allows you to interact directly with hardware. Something other languages abstract, meaning you have no ability to do much of anything advanced. You can't write drivers in Java.

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.

@WHYUNODYLAN

Ай бұрын

She also did a ton of work getting Rust to have functional FFI with many different C compilers. She is absolutely the person to defer to on this kind of stuff.

@JArielALamus

Ай бұрын

Does that not confirm the so called "skill issue" then? Because She's an expert with unsafe Rust not a C expert. Nevertheless, that is still experience she got for unsafe Rust interfacing with ABIs. Judging by the other comments here, it seems the ABIs goes deeper than just C

@WHYUNODYLAN

Ай бұрын

@@JArielALamus for one thing, I'd wager she's more of a "C expert" than most good C programmers are, since compiler people generally need to know a lot more specifics about languages. For another, I assume "skill issue" was a joke response to the "you can't actually parse C" claim.

@JArielALamus

Ай бұрын

@@WHYUNODYLAN I don't know about that. I have seen the responses to this article and for the looks of it, she is indeed talking outside her area of expertise. I'm not an expert either, so I can't say for sure, I can only go by the information I'm seeing. Also, by those same responses, it seems working with unsafe Rust is a really challenging task. I'll take a deeper look into all of this, I may learn new things. Anyways, thanks for pointing out about the Rustonomicon author

@turun_ambartanen

Ай бұрын

@@JArielALamus No, she is in fact an expert on this exact topic.

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

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

@phillipsusi1791

Ай бұрын

Sure, you can make a syscall directly... if you know what ABI the kernel that you are running on speaks. And even the same kernel running on the same CPU can speak different ABIs.

@digama0

Ай бұрын

Ok... this observation doesn't make it any easier for languages that aren't C to be able to call functions defined in C header files that contain the text "__int128" in them

@digama0

Ай бұрын

Also, calling syscalls directly is not supported by any OS except linux IIUC. For example windows requires that you link to KERNEL32.DLL and call functions there instead of syscalls, and the API for it is defined in windows.h which I'm sure contains every possible horror you can find in C.

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

@jamesburgess9101

7 күн бұрын

Back in the early 90's the Texas Instruments C40 DSP C compiler had char at 32 bits. Actually was a pretty nice dev environment though, I enjoyed it. It had an interesting harvard-like yet flat single address space

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?

@ChrisStavros

Ай бұрын

Her core thesis is that writing a standard library for systems is impossible because you HAVE to either use libc or write assembly, and "of course" writing assembly is impossible, therefore it cannot be done without C.

@AntsanParcher

15 күн бұрын

Everyone gets so hung up on the syscall example and completely misses the FFI thing, which is not about syscalls only, but also about how you make different programming languages *of any kind, in any situation* interact with each other. I don't know about you, but when I'm programming in CL and trying to get a compute shader to run, I'm not gonna try and figure out how to do it in Assembly, especially if I want what I'm doing to be portable.

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

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

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.

@evanrhildreth

Ай бұрын

Don't forget 80 bit floats!

@phoneywheeze9959

Ай бұрын

I'm not that deep, but if the authors problem is not being sure if int is 32 bits or 64 bits, why not use malloc and pointer?

@phillipsusi1791

Ай бұрын

@@phoneywheeze9959 That doesn't really have anything to do with it.

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.

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

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.

I don’t C any problems here

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

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.

No more netflix = no more hoodie?

@sutirk

Ай бұрын

The hoodie was company property

@deudz

Ай бұрын

we need to give him a new hoodie

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.

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

@lauraprates8764

Ай бұрын

at a time it was compiler dependant, but nowadays they shift to be platform dependant, but there's a reference definition for the minimum size of each integer, and the minimum size of a int is a 16bit integer

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 😅

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.

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)

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.

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.

@deth3021

Ай бұрын

Not on all systems and not by the standard.

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

@lauraprates8764

Ай бұрын

size_t is always unsigned and it's the type returned by the sizeof operator

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.

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.

@kuhluhOG

Ай бұрын

With the exception that the article stated that two compilers (gcc and clang) disagree on the interpretation of a part of the SysV ABI.

@Exilum

Ай бұрын

There was a mention of the SysV ABI being problematic too.

@sellicott

Ай бұрын

@@kuhluhOG IIRC I read through the AMD64 SysV abi when I read this article a while back. 128 bit integers aren't really defined in the ABI so each compiler is free to do whatever. The answer is that if you use weird types on function boundaries you are likely going to have problems, just push it to the stack.

@peppy3519

Ай бұрын

@@kuhluhOG this is probably Cs fault and not the ABI, or the ABI is just badly written. But there's no use of changing it now

@peppy3519

Ай бұрын

@@Exilum I don't think it's the bigger problem here. It's that languages are trying to parse C instead of linking with it. C *should* be like any other language and adhere to the ABI.

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

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.

@johnbennett1465

23 күн бұрын

In the 80's I worked on spell checkers for typewriters and handheld devices. Even when a C compiler existed for the obscure CPUs being used, it was generally buggy and failed to even meet the loose "standard" provided by the original K&R book. It sounds like it is a little bit better now, but still a big pain.

@AntsanParcher

15 күн бұрын

I thought that's what Forth was for.

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

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.

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

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.

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.

@infastin3795

Ай бұрын

C didn't really have standard intX_t types back then. So I believe when you don't have a way to explicitly specify the size of an integer you start to assume sizes of int/long.

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.

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.

@theheadpriest

Ай бұрын

because when you do embedded you know the architecture of the machine. PC codebases need to be able to run on different types of machines with minimal changes.

@sorek__

Ай бұрын

@@theheadpriest on PC you have 2-3 architectures. In embedded you can reuse same codebase between dozens architectures and 8, 16, 32 bit processors with different endianess.

@kablouserful

19 күн бұрын

​​@@theheadpriestif you need a different data for your platform (eh memory address) then you should write a new program.

I love C in the morning.

C is the means by which all is revealed.

@illuminoeye_gaming

Ай бұрын

the fall is coming

@j.trades9691

Ай бұрын

C-ing is believing.

C MENTIONED LETS GO

@jwr6796

Ай бұрын

Go mentioned!

AI = Productivity goes up, quality goes down

@3polygons

Ай бұрын

^^This. (Not sure about the productivity, either).

@thingsiplay

Ай бұрын

@@3polygons "Productivity" in the sense of "Quantity". I just used that term in sarcasm manner as an alias for quantity.

@3polygons

Ай бұрын

@@thingsiplay I see.. :)

@Mayhzon

Ай бұрын

@@thingsiplay Does it, though? Can't speak for programming but what I've found with art is that you end up trying and trying so much to make it work with prompting, you'd be better off having it done professionally by someone with experience in the first place.

@thingsiplay

Ай бұрын

@@Mayhzon That's because you are not satisfied with the many produced content. You produce a lot, meaning high quantity, with low quality. That's why you are looking for a professional. So my statement aligns with your statement as well. :-) voila

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

@zeratax

Ай бұрын

idk where it says that?

@krux02

Ай бұрын

@@zeratax It's the thing with "long". What is a "long"? How many bits does it have? What's the alignment? C does everything it can do to not give an answer to that. It all depends on the OS-cpu combination. If you work on a programming language, you want things like that to be hammered in stone.

@zeratax

Ай бұрын

@@krux02 i just don’t see where exactly the article states that every other language should do this instead of c. all i see is the author describing why c is a protocol and not a language and how insanely complicated this problem is.

@infastin3795

Ай бұрын

​@@krux02but you don't really want such things to be hammered down when you are writing your own os or a compiler for your own platform.

@digama0

Ай бұрын

She, not he

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.

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

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.

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?

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.

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.

@AloisMahdal

Ай бұрын

I thought it was obvious, since CSS stands for CpluSpluS. (right?)

C is actually just a really thin wrapper around assmebly, and thus dependent upon the processor architecture it runs on. That picture with the "kissing C"s? That is not the C protocol, that is Intel CPU protocol (specifically x86-64). Note e.g. that the image refers to "X87" which was the floating point coprocessor that Intel CPUs used until the FPU was integrated into the CPU starting with the 486 processors. (EDIT: I see later on ARM is mentioned...) If the author of the article was looking for the "procotol" for e.g. ARM, they would find something different (that did not reference x86-64 registers). It would not be much nicer though. Hiding parameter passing behind a nice syntax is one if the things C does for you. It is actually fairly doable to know what assembly a C compiler produces when optinization is turned off. And even with optimization, you can have a fair idea... So yes, it was a design decision for C to have "int" be a register size, based on the assembler wrapper thought. Then implementations diverged on 64 bit machines domr opting for backeards compatibility, some for sticking to the original defintions. Then the bit sized types where introduced. Gues you built up some cruft when, like C, you're in your 60s... So yeah, I understand their pain, but a lot of it is due to programmers not caring that e.g. intmax_t does not have a fixed, defined size but is plattform dependant. So either use wít with care, lots of sizeof()s, or avoid it. If you depend on intmaxt_t having a specific size, your program is effectively bugged or not protable. The FFI would imhop be entitled to let it crash.

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

@juanmacias5922

Ай бұрын

IT'S AN EXPERIENCE!

@0x90h

Ай бұрын

@@juanmacias5922 IT'S A JOURNEY!

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.

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

@phusicus_404

Ай бұрын

Hi, this is nice, how do you do that?

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

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

@eightsprites

Ай бұрын

Did someone meantion Perl?

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

size_t is what int was supposed to be… But it's really a pointer-sized integer. int is either 16 bits on 16 bits platforms or 32 bits in 32 and 64 bits platforms… long is 32 bits on 16 and 32 bits platforms, and 64 bits on 64 bits platform… In general… There are nuances there too… long long is 64 bits.

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.

Still a language, but also a protocol.

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

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

@phillipsusi1791

Ай бұрын

Sounds like the Zilog Ez80. A bastardized kind of 24 bit extended version of the 16 bit 8086. The address space was expanded to 24 bits, so that was the size of int ( and pointers ). and *some* ALU operations could be done in one instruction using 24 bit registers, but not all. Thus, int was 24 bits, but long was 32.

@vytah

Ай бұрын

@@phillipsusi1791 I found it, it was the MPLAB C18 compiler for the Microchip PIC18 family of microcontrollers, both long short and short long are allowed and mean the same. It's also not C11-compliant due to 32-bit doubles.

"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

The C/C++ short, int and long are always integers that have defined minimum size and the actual size is whatever the hardware can support with maximum performance. If some hardware can process 64 bit integers faster than 16 bit or 32 bit integers, short, int and long could all be 64 bit integers. That was the theory anyway. In practice, due historical reasons compilers must use different sizes as explained in the article. The reason we have so many function call conventions is also performance. For example, x64-64 sysv calling interface is different from x86-64 MSVC calling convention because Microsoft interface has a bit worse performance because it cannot pass equally much data in registers. And because we need to have backwards compatibility as an option, practically every compiler must support every calling convention ever made, no matter how stupid the convention was from technical viewpoint. It would be trivial to declare that you use only packed structures with little endian signed 64 bit numbers but that wouldn't result in highest possible performance. And C/C++ is always about highest possible performance. Always. That said, it seems obvious in hindsight that the only sensible way is to use types such as i32, i64, u128 and call it a day. Even if you have intmax_t or time_t somebody somewhere will depend it being 64 bit and you can never ever change the type to be something else but 64 bit. It makes much more sense to just define that the argument or return value is i64 and create another API if that ever turns out to be bad decision. The cases where you can randomly re-compile a big program in C/C++ and it just works even if short, int, long, time_t and intmax_t change sizes is so rare that it's not worth making *everything* a lot more complex. The gurus that were able to make it all work with objects that change sizes depending on underlying hardware will be able to make it work with a single type definition file that codes optimal size for every type they really want to use.

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

Can't we all just get a long?

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.

@digama0

Ай бұрын

You should check out the link given for "parsing C is basically impossible" in the article, which contains such beautiful test cases as: typedef long T, U; enum {V} (*f(T T, enum {U} y, int x[T+U]))(T t); // The above declares a function f of type: // (long, enum{U}, ptr(int)) -> ptr (long -> enum{V}) T x[(U)V+1]; // T and U again denote types; V remains visible These are some absolutely hellish things which even existing compilers get wrong, and writing a correct parser from the pile of prose rules in the C standard is not at all clear, especially when there are mistakes in the standard as well (some pointed out in the same paper). The paper's title is "A Simple, Possibly Correct LR Parser for C11" - even after that in-depth investigation the authors still can't claim to have a correct parser for C11. If you think it's "just a matter of putting in the work" I think you don't understand what you are up against. Then again, if you are okay with being wrong in a bunch of edge cases then yes, it's comparatively simple, and nothing to apologize for either, even the big leagues are doing that because the actual C standard is bonkers.

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.

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

Roman numeral rules? Short long is longer or shorter than a long short?

C is almost a real programming language. Assembly is the real programming language, except that assembly language is a collection of hundreds of wildly different languages. Z80 assembly is very different from PIC16 or DSP56k or S08 or S12X, ARM, IBM 370, RGP30… all different. That’s the source of the type/size issues in C. I’m lucky enough to program embedded systems but even then, C isn’t the same between different processor platforms.

as a C and C++ embedded SoftEng I'm in the unique position to understand size_t as an important type. you see, when making cross platform code that handles memory you need an (usually unsigned) integer type that is guaranteed to line up with pointer types within the system. this is done to reduce or avoid conversions when performing pointer arithmetic or storing pointers as address values(see how C handles ++ operator or addition with any type pointers, and why) when seeing how those things operate on a basic level you get to understand why those inconsistencies exist, and why for anyone above system/embedded those language types should be used either as a "I just need whatever type here" for things that are not cross platform, or not at all. leave it for people like me to know which type to put in the "int64_t" typedef line as we are already making and dealing with stupid system defines on a daily basis and need those system specific types for many things. lastly. even where I work, no one wants to touch "long", it's a remnant of the transition out of 16bit to 32bit and was therefore 32bit originally. "long" in contrast to "short". but what about int? who the fuck even knows at this point? those types were used by people back in the days where the use of typedefs was basically reserved for structs and unions, when token-pasting wasn't even a thing yet, and many more stupid limitations, they didn't know any better.

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

Int max is not the max lolllll 😂 I feel the pain. Long long supposed to be 128 bit, to my knowledge a long time ago. Long long long is 256 bit but only works on computers that have dual channel DDR setup.

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

long long short long is somewhere around 32*sqrt(2) bits, perhaps could be added to the next standard

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

@faetalize

Ай бұрын

no, it's for emphasis

@aarholodian

Ай бұрын

Reddit spacing

@thingsiplay

Ай бұрын

@@faetalize For people who can't read?

@faetalize

Ай бұрын

@@thingsiplay are you implying anything? this style of writing is popular with young people. it is styled differently than older folks might be used to, but this is right up my alley as a twenty-something years old. one sentence in a paragraph for the purpose of emphasis is quite common for our generation

@thingsiplay

Ай бұрын

@@faetalize It doesn't matter what generation it is, I dislike the way how the article is structured.