> I've never been on a system where sizeof(char) != 1

And you never will, since sizeof(char) is guaranteed to always be 1.

I'm guessing you were thinking of CHAR_BIT != 8, but even then I'm not sure it would make a difference since malloc takes its argument size in bytes and a char more or less is a byte in C.

(Consider that char*s are also how you access the byte-level representation of objects in C. If chars were not the minimum addressable unit then that use wouldn't work)

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