The Rust stdlib has added those functions that return errors, and the types are parameterized by the allocator trait. The trait is coming to stable in the next release!

In userspace/application code this isn't giving you all the value you hope for - because of overcommit and fork/exec, you can OOM on simply modifying a variable (in a non-file-backed page).

What Zig does is great, but it is not actually comprehensively checking that all allocations are fallible and handled. That's not possible on Linux.

No one does this. The best you can hope for is that a rare few especially error prone allocations (perhaps they are huge, or user controlled) are handled. Someone might I suppose also wrap all malloc calls in a function that shows a dialog or error message and only then exits. But returning all the way to the top, yeah.. no..

recently noticed that iced (rust ui framework) crashes on oom - from the logs it seems to be aware and crash explicitly. I wish it would just reduce the fps or hang a bit instead of crashing, perhaps use exponential backoff

How is it then that my stock KUbuntu system won't let me allocate 50,000,000,000 bytes?

  $ uname -a
  Linux boxcar 7.0.0-31-generic #31~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Aug 10 09:38:02 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
  $ cat tmp.c
  #include <stdio.h>
  #include <stdlib.h>
  
  int main() {
  char *s = malloc(50000000000ULL);
    if (s == NULL) {
      printf("Boo, hoo!\n");
    } else {
      printf("Look at all that memory!\n");
    }
    return 0;
  }
  $ cc tmp.c
  $ ./a.out
  Boo, hoo!

To get back to the essay, I can easily understand why someone who has Rust as their first-and-only systems language, and therefore expects abort-when-out-of-memory, will not immediately consider how C allows a different approach to how to handle that condition, but instead will try to replicate Rust's behavior in C.

"I can program FORTRAN in any language." :)

(And CHAR_BIT is required to be 8 by POSIX, so even though the language and some exotic hardware will have it at non-8, it’s exceedingly rare at this point.)

The linked-to essay points out that char is only "at least 8 bits", and links to https://cppreference.com/c/language/arithmetic_types which confirms that point.

https://smd.hu/Data/Analog/DSP/SHARC/C&C++%20Compiler%20&%20... says the cc21k compiler for ADSP-21xxx DSP systems has char as 32 bits signed, and that the compiler handles ANSI/ISO standard C.

So I don't believe your statement "sizeof(char) is guaranteed to always be 1" is correct.

> chars are also how you access the byte-level representation of objects in C

Where does the spec say that a char can be used to address any point in an object?

There's all sorts of oddities like tagged architectures which the C spec handles which I know essentially nothing about, but which break common expectations about how C works. I believe this is one of them.

I believe the following is undefined behavior in C, even though your compiler may let you do it, at least sometimes, and on modern desktop hardware:

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

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