C for Rust programmers (bd103.dev)

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.

> This is not a substitute for a proper C tutorial

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

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.

Asan!

A Rust programmer, programming in C is a C programmer!

Tribalism is sooo ... sadly now.

Please don't.

real musicians don't build identities around instruments (i.e. don't call themselves pianist, violinist or singer).

(I say this as an aspiring C major pianist.)

in an ideal world real programmers wouldn't be building their whole identities around publishing libraries like "isEven" or claiming fame for vibe porting perfectly fine libraries into whatever is the newest and hottest platform...

... but that ship has already sailed

All fun and games with arrays being pointers, until you declare an array in a function and return it.

Isn't Lisp even more bare bones?

At end of day minimalism is a neat but not decisive feature. If minimalism was decisive we'd all be writing Brainfuck.

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

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.

> C is wonderfully simple at times.

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.

[0] https://www.youtube.com/watch?v=W-ryv6TwQvM

As fun as it is, 1[c] will be "marked obsolete" in C29 according to Wikipedia.

> but nobody in decades thought to make this information accessible to the programmer

Isn’t this implementation details, and an information already available caller side. It would be like returning the filename for a file handle. The more extraneous details in an API, the less flexible it is.

> nobody in decades thought to make this information accessible to the programmer!

Obviously this is untrue. Under GNU we have malloc_usable_size(3). What's true is that it never became standardized, but standards for just about anything in C are very bare, so it's not too surprising.

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

The way C handles (prior to C23) booleans is pretty close to how you'd handle booleans in assembly.

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.

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.

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.

GLib simple C data structures:

https://docs.gtk.org/glib/data-structures.html#doubly-linked...

GSL GNU Scientific Library for C:

https://www.gnu.org/software/gsl/doc/html/intro.html

In general, no one should be custom building most basic structures in C these days. =3

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

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

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.

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. https://news.ycombinator.com/item?id=49697392

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

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

        — C.A.R. Hoare, The 1980 ACM Turing Award Lecture

It is impractical to try to recover/continue your program in an out of memory situation for most programs.

So it is a good advice for beginners.

Agreed.

I think it's because the new_uninit_slice call Rust will trigger a panic? Or abort? With little-to-no chance for recovery? (I know little about Rust.)

If so, I can see why someone that someone coming from Rust might consider exit() to be the appropriate solution for C, even for library code which should never be in charge of deciding how a program should exit.

I think the essay could be improved by highlighting the different worldviews.

I'm also old enough that

    // Allocate enough room for the string and its null terminator.
    char* reversed = malloc(len + 1);

makes me nervous. Even for char -- I've never been on a system where sizeof(char) != 1 -- I want to see the sizeof included in the calculation, like:

    char* reversed = malloc((len + 1) * sizeof(*reversed))

so I don't have to think about sizeof(char) being special.

As long as I'm here, I'm a bit confused about the purpose of the "char* error_message" in the proposed Result. Why a char* vs a const char * or even better, an int with an error code? Who sees the message? Do we expect they know English, or will they be localized? Will the error message text be frozen forever, or might it change in the future?

  int i = 12345;
  char *s = ((char *)&i) + 1;
  char c = *s;

  char tmp[sizeof(int)];
  memcpy(tmp, &i, sizeof(int));
  char c = tmp[1];

Probably because C and C++ are mostly used in system and desktop development.

Rust is taking steps or has been taking steps in this direction too.

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

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.

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.

That's interesting - to me C is delightfully austere. Most other languages, even much younger languages like Rust, spiral in complexity as they mature. But C hasn't grown much more complex since C99. How many other (mainstream) languages can say that?

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.

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 have 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 address not the whole pointer.

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.

In C, mostly you think about your code running on the machine with some thought dedicated to the compiler gymnastics involved during the compilation phase.

With Rust, you are front loaded with a myriad of compiler gymnastics you need to think through.

But once you get comfortable enough, it becomes natural. You also have to get accustomed to writing code that is more verbose than C which might look ugly at first but later you start to accommodate it as the necessary cost for the utility you are handed in return by the compiler.

For example, multiple variables in Rust doesn't necessarily mean multiple memory allocated variables at runtime like in C. The rust compiler will usually keep track of and ensure multiple variables (non Copy types such as String with Move semantics) map to one memory allocated variable at runtime (in normal single threaded use cases under normal circumstances without using RC, ARC, etc.). Eg: let a = String::from("hello"); let b = a; ... Note: The example is for illustration purposes only and not always true. In summary source code variables are abstractions and may not belong to distinct runtime memory location. Yes it is true even for C. But Rust's ownership model makes that distinction aggressively visible.

Not a regression. Most of the systems code you'll ever touch is still C, and knowing C makes Rust's unsafe blocks and FFI story way less mysterious. I learned C after Rust and it changed how I read Rust too: the ownership rules click differently once you've managed memory by hand and felt the bugs they prevent.

It is easier to write a C compiler from scratch than a Rust compiler from scratch. No usage of LLVM or anything like it.

That also reflects in that many embedded systems offer C support and do not offer Rust support.