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];