On a relative scale, C is very low level compared to how we program today if you think about levels of abstraction.
If “low level” means “runs on the CPU almost literally as written.” then no it’s not.
Ada has System.Address to model machine addresses:
http://ada-auth.org/standards/rm12_w_tc1/html/RM-13-7.html#p...
C++ has std::less specializations for pointer types which provide a strict total order (one aspect of machine addresses):
https://en.cppreference.com/w/cpp/utility/functional/less
There is also placement new and std::launder for more explicit control of typed memory:
https://en.cppreference.com/w/cpp/language/new https://en.cppreference.com/w/cpp/utility/launder
These days, even Java tries to model machine addresses:
https://docs.oracle.com/en/java/javase/21/core/foreign-funct...
IRs like LLVMIR and various bytecodes. Well, those don't map to the hardware 1:1, not even close. So IR must be HLL.
Sure Asm has to be architecture specific, but even then we are getting pretty good at transpilation. And those codes get translated to opcodes anyways on most modern chips.
Basically, unless you are assembling on an ancient system or embedded processor, you aren't writing in a "low level language". Very few folks nowadays do this, so the term "LLL" doesn't occupy much mindshare in semantic space. That leads folks to populate it with what they perceive as low level - the lowest language on the abstraction tree they are likely to encounter - C.
This divide is only going to expand so I say we just accept the definition of low level language has shifted, and call anything where it does closely match... something else, I don't have a good term. Maybe "hardware level language".
But doesn't this still depend on what CPU you're talking about? Your C code will map much more closely to the instructions of the machine code of an 8051 or even an M4 than it will to an x86.
Thus any general-purpose language is more or less "low level" depending on the CPU it's running on. This seems like a poor definition.