Any tutorial for C should explain compiler warnings and other tools that help make code safer. In C, you do not rely on the language specification but on tooling. Especially for Rust programmers, this needs to be explained more explicitly. And of course, you can build abstractions using types in C. So a tutorial should also focus on that, and perhaps not start with a low-level string reversal function.
Absolutely. Turn the warnings into errors too, build and test with sanitizers (ASAN, UBSAN, TSAN) when not measuring performance, and use static analysis beyond compiler warnings (Clang Tidy, Clang Static Analyzer).<p>Though the author doesn't look to be trying to write a great tutorial, rather prioritizing sharing what and how they learned something from their perspective.
Maybe the author was given monetary support from the Rust Foundation, they have given money to people to write blog posts <a href="https://rustfoundation.org/media/introducing-our-newest-project-grantees/" rel="nofollow">https://rustfoundation.org/media/introducing-our-newest-proj...</a> . They love media instead of technical work.
> Turn the warnings into errors too,<p><i>Please</i> stop smashing all the nuance out of compiler diagnostics this way.<p>One of the biggest successes of Rust has been its great diagnostics and I can assure you that it would <i>not</i> help to smash my Clippy lint suggesting that what I wrote looks a lot like an implementation of the addition operator† into a fatal error like the one I get for forgetting to initialize a variable.<p>Rust even has a (begins empty) diagnostic category [named "expect"] for "This warning should be here" which will flag cases where a notable thing not only <i>might</i> happen here and if it does we can ignore that, but if it's no longer detected that is itself suspicious and should be diagnosed.<p>† Yes it does Clippy, and I considered implementing Add but I had a good reason not to, so here is a suppression annotation.
> This is not a substitute for a proper C tutorial
I'm with you. Since the post already shows Clang catching the array-decay bug, the author could even just add a “always build with -Wall -Wextra -fsanitize=address,undefined” note and some explanation of course.
Asan!
Re: arrays are pointers.<p>One of my favorite things to show just how bare this is in C is to show array access commutativity.<p><pre><code> char c = {1,2,3}
c[1] == *(c + 1)
*(c + 1) == *(1 + c)
c[1] == 1[c]
</code></pre>
C is wonderfully simple at times.
I have known about this for quite some time, and the more I think about it, the more useless it seems. Sure, the underlying machine operation is just addition, which is indeed commutative, but at the type system level, the pointer and the offset have distinct roles. It just makes no sense to allow to commute them, just like it makes no sense to allow to commute arguments to, say, strchr, just because the compiler can figure it out by looking at the types. When was the last time you had a practical reason to write "offset + pointer" or "index[array]"?<p>In most languages, the indexing operator is not commutative. In Rust, pointer offseting is expressed as a function call or a method, also not commutative. I have never seen a single complaint about either. It's not something people want or care about, it's just a tedious detail.
> It's not something people want or care about, it's just a tedious detail.<p>It’s not something idiomatic, but indexing in C is syntactic sugar. Not sure why they allow it in the syntax, but forgetting that arrays are pointers and not special type is just asking for bugs.
Arrays are not pointers in c. Though they are very similar and will implicitly convert, there are differences. The big and obvious difference is that declaring an array will allocate space for it. In a function, on the stack. In a struct, inline. They have different sizeof. I think there are also some other stuff I can't remember.
As fun as it is, 1[c] will be "marked obsolete" in C29 according to Wikipedia.
All fun and games with arrays being pointers, until you declare an array in a function and return it.
Isn't this easily catchable with static analysis, -Werror -Wall? I've never had a practical problem with this.<p>Also arrays aren't pointers in C, they decay into pointers. You can see this since sizeof will work differently in the function that instantiates the array versus one that takes in the pointer as a parameter.
> C is wonderfully simple at times.<p>Yesterday, I watch a quick video[0] where Matthew Butterick was comparing book sizes and their appeal. “The C Programming Language” was my second programming book (after one about JavaScript 1.x) and I still remember it fondly. Easy to start with (with CodeBlocks on Windows and gcc on Linux) and the concepts were nicely explained. The book were also very nice.<p>[0] <a href="https://www.youtube.com/watch?v=W-ryv6TwQvM" rel="nofollow">https://www.youtube.com/watch?v=W-ryv6TwQvM</a>
Isn't Lisp even more bare bones?<p>At end of day minimalism is a neat but not decisive feature. If minimalism was decisive we'd all be writing Brainfuck.
Lisp minimalism is very different. It assumes a runtime with automatic memory management for example, even if the language concepts themselves are minimal, especially in Scheme, it has almost no syntax and just a few core facilities on top of which everything else is built, which are closely related to the Lambda calculus, kind of ignoring completely what real computers actually look like.<p>In C the minimalism comes from providing only the minimal set of things that are available in most (maybe all) architectures (the Von Neumann paradigm), like linear memory, a simple function calling convention, close mapping to Assembly operations etc.
But C syntax is not very minimalist compared to Lisp , let alone Forth. The fact that C syntax became prevalent in the programming world seems to be mostly an accident to me, it’s not objectively better than those minimalist languages’ or Pascal’s, Prolog, ML families.
I would add on top of brabel's post that C is surprisingly difficult to parse correctly (C++ notoriously so).<p>Zoom out a little: C is a lot like Unix: simple probably isn't the right word; `underengineered` comes to mind. Which leads to complexity, as you need to make things work in the real world. And so Unix syscalls being designed in the early 1970's for a PDP-11 don't really map to modern needs. And so every unanalyzed complex C app has memory leaks.<p>To be clear, I like C, I like C++, I like Objective-C, I like Swift; I'm comfortable in all of them. But, in 2026, I don't see why for native code everyone shouldn't be programming in Rust / Swift / other modern memory-safe flavor for any new production use. Zig if you want faster compile times, I guess.
> But, in 2026, I don't see why for native code everyone shouldn't be programming in Rust / Swift / other modern memory-safe flavor for any new production use. Zig if you want faster compile times, I guess.<p>Because C is very simple (unlike Rust) and works everywhere. Zig is not yet stable. Go and Swift are under the governance of tech companies.<p>The true appeal of C for me is the standard and how it applies only to the language. You can easily take a project from 2 decades ago and port it to a current platform. Lot of current ecosystem is way too fussy about tooling to do this.
> One of my favorite things to show<p>Who have you shown this to? What kind of person is impressed by this? Anyone that programs in any other language already knows that syntax is fungible so who cares if C chooses to use addition and brackets this way. So the only people that might be impressed by this are people who don't program. In which case why are you showing them lol.<p>For example (assuming you're a C programmer) are you impressed by this python syntax<p><pre><code> [a] * 3 == [a, a, a]</code></pre>
> Woah, iterating over pointers instead of indexes! […] However, I'm not sure how good an idea that is.<p>I’d recommend anyone (including the author) wanting to understand C to read K&R’s “The C Programming Language”, which among other things will illustrate how iterating over pointers is idiomatic in C (though not quite in the way the author’s example does it).
GLib simple C data structures:<p><a href="https://docs.gtk.org/glib/data-structures.html#doubly-linked-lists" rel="nofollow">https://docs.gtk.org/glib/data-structures.html#doubly-linked...</a><p>GSL GNU Scientific Library for C:<p><a href="https://www.gnu.org/software/gsl/doc/html/intro.html" rel="nofollow">https://www.gnu.org/software/gsl/doc/html/intro.html</a><p>In general, no one should be custom building most basic structures in C these days. =3
I'm going to go out on a limb here and make a wild guess.<p>That boolean is actually mostly an extension of the integer system whereby we now have an integer type that stores only one bit.<p>Whereby the bit stored either results in a 'true' or 'false' value.<p>Anyways, I know booleans are useful in systems development when you have strict memory / storage constrains / bandwidth (networks).<p>Yeah, that works for me.
The way C handles (prior to C23) booleans is pretty close to how you'd handle booleans in assembly.<p>CPUs don't have types, everything is integers or floats. You do your work on registers which have fixed sizes. CPUs have built in instructions for "is this register not zero" which leaks into C. 1 is true in C, but so is 2.<p>Also, single bits are rarely used for booleans because it requires more CPU power to extract a single bit. Everything is byte aligned at a minimum.<p>When doing something like network code, if you want to store a bunch of booleans you are typically going to either pack them into a byte, or you'll burn the extra bits and send a single byte for the boolean value. Typically this was flags and masks.
> Also, single bits are rarely used for booleans because it requires more CPU power to extract a single bit.<p>Not necessarily, on modern CPUs memory access is often the bottleneck. If you have many bits storing these in a bitarray can be quite beneficial for performance.
> single bits are rarely used for booleans<p>SQL Server still has no boolean type and groups bits in the same row into a byte if possible.
'bool' is still at least 1 byte in C. If you want to store one Boolean per bit you have to manually implement a bitmap.
A bool does automatically cast to an unsized bit slice.<p>Meaning, if you have a struct and you want to bit-pack your booleans, you can declare each one as, say, uint8_t some_bool : 1;<p>You may then do `x.some_bool = true;` etc.<p>It's a small nicety to avoid bitwise operators, anyway.
Or pull out the C++ and use std::vector<bool>,... But you should probably never do that
[dead]
> the program should check for a null pointer and gracefully exit if one is found: ...<p>If malloc() fails, there is no need to exit the program completely with exit(), only return from the current function with an error.
It's beautiful to see this perspective! The fact that we are at "whoa, C is fucked up compared to my expectations" instead of "look at Rust's fancy safety stuff" shows that as a field we've started lifting the baseline.<p>Nowadays I actually believe I'll likely see a world without memory corruption within my lifetime.
Focusing narrowly on memory safety is frequently a distraction that incompetent developers use to excuse their buggy code. "Sure, my Rust code might cause deaths and cause millions of dollars lost; and my code might be unsafe, insecure and incorrect; but at least my code is memory safe and easy to debug when I fuck it up!". And then it often turns out that Rust is not memory safe in practice. <a href="https://news.ycombinator.com/item?id=49697392">https://news.ycombinator.com/item?id=49697392</a><p>The real value of Rust is likely pattern matching and tagged unions. Apart from modules/packages that are not a disaster, like Gabriel Dos Reis the saboteur's disaster with modules in C++.
My take too. (Aside from this being a well-written, clear article, that I think highlighted a fair selection of relevant points; especially the "always use uint8_t instead if int" part).<p>I don't see rust a "memory safe" language, or a niche one. I have complaints about it etc, but it's overall a fair baseline of reasonable decisions. When I look at C or other languages rust has learned from, I have more "Yikes, that's rough" takes. So... rust as the language of least "fucked up", to use your phrase? Ownership/safety are one part of the picture, but not what defines it for me.
> Rust<p>> least "fucked up"<p>C has the excuse that it is ancient, but it is tiny and has a lot of different implementations. Rust gccrs is still crawling along, fixing up the huge holes in the Rust "specification" along the way.<p>To Ygg2:<p>Why do you lie? Please stop being dishonest, incompetent and schizophrenic.<p>> Ferrous Systems Achieves IEC 61508 (SIL 2) Certification for Rust Core Library Subset
Is this the sort of thing you only need to know about if building/maintaining compilers? I ask because I don't know what that means from a practical perspective. I'm familiar with Ferrous systems from their work on probe-rs, defmt, and flip-link, which are exquisite libraries / tools.<p>edit: I think this is a bot or troll account.
Rust never had a goal of having well defined spec. It all depends on what ecosystem wants.<p>In lieu of that it didn't fuck up.
It’s definitely great that memory safety is becoming more pervasive. Though I’ll believe “a world without memory corruption” right up until another <insert your relevant hacker hero name> comes along and finds a way through an unsafe block, an FFI boundary, or the hardware itself (Rowhammer says hi).
> Rowhammer says hi<p>Yeah I was thinking of prefixing my "memory corruption" with "software-bug induced"! I don't see a credible solution to Rowhammer. ("DDR[n+1] fixes it" - lol)<p>> an unsafe block, an FFI boundary<p>Honestly these feel solvable to me at this point! I think we'll see:<p>- unsafe code shrink as languages get more powerful<p>- amount of analysis we can apply to each unsafe line shoot up exponentially as AI gets cheaper<p>- amount of FFI we actually need shrink as it gets easier to just click "rewrite it in $lang" on the decision card when your coding agent says "I found a library for that but it's in a different language"<p>(Having said all of that, people seem to be adopting Zig for some bizarre reason... So maybe I'm naive to expect unsafe lines to shrink)<p>(But also, maybe AI gets so good and so cheap that we can just type "go fidn all the bugs andfi xthenm" into an LLM, between sips of a Piña Colada)
I'm one of those people who's adopting Zig :) But I don't think it's best for every project. For context, I've used Rust before for probably two years writing a realtime audio synthesis engine, so I'm fairly familiar with Rust vs Zig for handling low level details.<p>The biggest reason I use Zig is it's a very explicit language. The creators made a very intentional decision to avoid too many "high level" designs. This doesn't mean there's no capabilities for abstraction (comptime is great for that), but when you see array indexing, you can think "ptr + index * size with bounds check". There's lots of other things like that where the language does exactly one thing, and that thing is a low level operation.<p>This is terrible when you want to create high level abstractions that hide details from the programmer, but it's what I need when doing realtime audio synthesis or what I'm doing now which is writing an interpreter. I know exactly what allocates, I know what calls IO and can block (both operations explicitly take in an allocator or IO parameter), no data structures have private fields so I can always poke around at the insides. I know what types of errors a function returns, and creating errors is cheap with Zig's error union design.<p>So I don't use Zig because I think it's the safer language, I know it has sharp edges because of the number of times I've caused a panic on a poisoned pointer or use-after-free. But because it gives me such a transparent view into what is happening I find it liberating.
Read the following if you want to be a C Programmer;<p><i>Fluent C: Principles, Practices and Patterns</i> by Christopher Preschern - <a href="https://www.oreilly.com/library/view/fluent-c/9781492097273/" rel="nofollow">https://www.oreilly.com/library/view/fluent-c/9781492097273/</a>
<i>>The very first systems programming language I ever learned was Rust. This is uncommon compared to many other programmers; you're more likely to find someone who learned C or C++ first before coming to Rust.</i><p>It's becoming increasingly common. Rust is my first systems programming language too. I tried to learn C a few years ago but I found it too austere and prickly, which put me off.
That's interesting - to me C is <i>delightfully</i> austere. Most other languages, even much younger languages like Rust, spiral in complexity as they mature. But C hasn't grown <i>much</i> more complex since C99.
I was going to write that I found this odd. The kid that cuts my grass is going for a degree in CS and told me just yesterday that, in his second year, Java is the language he uses with a little Python. That C was such a struggle and he won't touch it.<p>For someone getting a CS degree, that just seems so, so odd. Along with that, he's been studying edge detection in images. In his second year. Not to run off topic but, again, I find that so, so odd.
When I was in college at a large Midwest university in 2002 intro cs classes were taught in C. Business majors were required to take cs 101 taught in C. We had a project that required implementing linked lists, oh how the business majors suffered! We all did actually but at least the cs majors could use the knowledge!
Probably because C and C++ are mostly used in system and desktop development.<p>Rust is taking steps or has been taking steps in this direction too.<p>It's not surprising that a lot of experienced systems and desktop development engineers looking to getting their hands on the newest tool already have experience or at least familiarity with C and C++.
It reads really well
isize and usize seem to be more like intptr_t and uintptr_t. To be fair, for a long time it was not very well-defined to which C type they correspond to; I think that was cleared up only recently.<p>It's also a shame the article uses the self-delusional C++ style of pointer declarators.<p>Otherwise pretty okay.
They're not great analogs to any of the C types because C and C++ have a different relationship to pointers than Rust does but particularly they are not intptr_t / uintptr_t because those claim that we can intra-convert between these types and pointers.<p>On a typical PC that doesn't seem like a problem, and it will (at least kinda) work which might give you the false impression it's required to work, which it very much is not in Rust. On CHERI it's obvious why this can't work. CHERI's pointers are 128-bit. Rust does <i>have</i> 128-bit integers, but Rust's isize and usize on CHERI will be 64 bits. Because only half of CHERI's pointer bits are address bits, and Rust told you that isize and usize were big enough for the <i>address</i> not the whole pointer.<p>Many clever pointer tricks only want to fiddle with the address. For example hiding bit flags in an aligned pointer works, as does hiding the entire value inline in today's enormous pointers (64 bits! Luxury) and using a single bit to mark "not a real pointer". In Rust we do these with the actual raw pointer types, they have methods like any other type, but in C or C++ you need to convert to a pointer-sized integer and then do tricks with the integer or you will write UB.
My own journey has been quite different.<p>When I was building my kernel in my late teens, I first wrote the bootloader by hand on paper in assembly language. I then referenced the x86 manual for the instruction set and converted my assembly code into the equivalent hexadecimal machine code values of the x86 machine instructions, which I also wrote by hand on paper. Then I used a hex editor on the desktop to manually write the hex values into a file and used it as the bootloader i.e as the first 512 bytes.<p>The whole exercise gave me a sense of hard grounded zero magic, raw, unfiltered experience. This is an experience that is hard to replicate in any other way. I deliberately did that so as to peel away as much magic/abstraction layers as I possibly can.<p>Later on when I started using C, I never had to learn C but merely just had to reference the equivalents of the assembly language. Like how the primitive "if" doesn't exist in the hardware but is a composition of cmp and jmp instructions. Seen this way, C becomes a glorified portable syntactic sugar over assembly language.<p>Then higher up the ladder to C++ for object oriented problem solving while retaining the spirit of functional programming. Rust was a breath of fresh air, where correctness across a myriad of use cases was a first class primitive.<p>Each abstraction layer can thus be evaluated for its utility in problem solving while its underlying mechanics remain understandable down to the hardware level.<p>More recently, our own arcc compiler extends correctness to our architecture and not just the types.<p>So if you are young and have time to spare, I suggest a little bit of assembly => C => C++ => Rust.<p>This essentially makes you immune to hype train bullshit.
Really just another use Rust instead of c article.
[dead]
> there are plenty of "Rust for C Programmers" articles on the internet, but little to no "C for Rust Programmers" articles out there.<p>Why would a Rust programmer learn C? Isn't that basically a regression?