memset(&i, 0, sizeof(int)); equivalent to i = 0;? memset itself usually implemented as a loop over 32-bit or 64-bit integers, depending on the machine register size. unsigned char uses ``a pure binary notation''1, which is defined like you'd expect: Every bit represents a unique power of two between 1 and 2CHAR_BIT-1, the value is the sum of the powers of two whose corresponding bit is set to 1. From this it follows that an unsigned char 0 consists of CHAR_BIT zero bits. All objects other than bitfields have an abstract object representation consisting of a contiguous sequence of one or more bytes2. C distinguishes between object representations and values; I don't want to dive into the irrelevant details of ORs too much, but the thing to keep in mind is that not every OR must correspond to a value and a single value may have multiple ORs.memset(dest, val, len), by definition, sets each of the bytes in the pointed-to part of an object's OR to (unsigned char)val. Therefore, your question is equivalent to ``Is all-zeroes a valid OR for 0 for all integer types?''. And the answer is no. Integer types are allowed to have padding bits which allow for so-called trap representations — representations that do not correspond to a value. You could use these to e.g. signal signed overflow or store parity bits.3 Use a scheme where a value of 0 requires set checksum bits and the memset trick doesn't work.unsigned char uses.4 Therefore they may not have trap representations and 0 is represented as all-zeroes. The only difference between unsigned and signed types is that signed types have a bit which is repurposed as a sign bit. Signed types may have trap representations even in the absence of padding5, but the value of a signed integer is defined as the value induced by the value bits as if you were dealing with an unsigned integer, fed into one of three operations6 if the sign bit is one. Therefore, an all-zeroes signed integer without padding bits represents the value 0.int i; memset(&i, 0, sizeof(i)); is in fact equivalent to i = 0;.CHAR_BIT must be at least 8 and an implementation on a 6-bit machine could provide an abstract ``C byte'' (the char) that consists of two ``real bytes'' and set CHAR_BIT to 12. unsigned char would then work like an unsigned 12-bit number."Usually" is not good enough to be considered portable.Theory and practice sometimes clash. And when that happens, theory loses. Every single time. --Linus Torvalds
For any integer type the object representation where all the bits are zero shall be a representation of the value zero in that type.§6.2.6.2.5
C is the worse replacement for other languages. Universities were ``forced to'' replace better languages with C in the late 80s and early 90s.C was replaced with the likes of Python and Java in Universities to create hoards of code monkeys for companies.
And C was both a systems and applications language in the 70s or 80sYes, but not as early or as important as you think it is. It's not like Java, which came out in 1995 and was a huge thing for web applets in the 90s. C didn't become popular until the Sun workstation came out and became more popular when Microsoft picked C for Windows.
The earlier compiler does not know about structures at all: the string "struct" does not appear anywhere. The second tape has a compiler that does implement structures in a way that begins to approach their current meaning. Their declaration syntax seems to use () instead of {}, but . and -> for specifying members of a structure itself and members of a pointed-to structure are both there.
Neither compiler yet handled the general declaration syntax of today or even K&R I, with its compound declarators like the one in int **ipp; . The compilers have not yet evolved the notion of compounding of type constructors ("array of pointers to functions", for example). These would appear, though, by 5th or 6th edition Unix (say 1975), as described (in Postscript) in the C manual a couple of years after these versions.
it was in fact TOO HIGH LEVEL to be used on 8-bit microcomputers.It was too bloated, not too high level. BASIC is higher level, but it's smaller (and usually interpreted).
Where are all of these systems and applications written in ``C without structs'' or ``C without compound declarators''?Basically the entirety of Research Unix, though it did have structs since 1973. You seem to be conflating ``Primeval C" with K&R C, even though they're two different dialects (and the former was only in use during the development of the first self-hosting C compiler).
BASIC is higher levelNot really, it doesn't support local variables, named functions, or structs. It's basically assembly language for a virtual machine. Calling it higher level than C is like saying JVM bytecode is higher level than C just because it incorporates the notion of "classes".
C allows pointers to both local variables and heap space to be declared the same, with no way for code to tell which is which. That brought us "near pointers" and "far pointers" that you just wouldn't need in a language like Pascal. Why? Because Pascal was really popular when the 8086 was being designed, so the hardware targeted the four independent memory spaces that Pascal has (code, stack, heap, globals/runtime). That was very painful for C, requiring bizarre extensions to the standard to handle. Even something like the 6502 compilers for C said basically "you can't write recursive functions, because all local variables are actually static."
The Burroughs B-series, for example, had typed memory. You could store a float in one location, an integer in another location, and issue an "add" instruction, and the CPU would upcast the int to a float and add them together. There was only one add instruction, not one add-floats, add-integers, etc. This is something that kept C from ever being ported to that architecture.
The verifone credit card terminal software can't support function pointers. There's just no instruction in the CPU to branch to a location that's not hard-coded into the instruction.
The Sigma-9 had two optional compute units: the scientific unit and the business unit. The scientific unit is what we'd call an FPU these days. The business unit did BCD math, converted decimal numbers to printable strings (the COBOL edit display instruction which was COBOL's version of printf formatting, for example) and block moves. C has no support for decimal math, so you would get much faster COBOL programs on that hardware than C programs.
The Dolphin had microcode specifically to support Smalltalk, which was an actual OO language, so again you couldn't put C on it because you can't have pointers into the middle of an object.
All these machines died, not because they were bad machines, but because they were really terrible at supporting C. They were too specialized. But that doesn't make C inherently a good system language. It's only a good system language today, because people wrote so much C code that hardware manufacturers didn't feel the need to keep supporting the other languages in hardware.
Nowadays, you have GPUs. Up until CUDA, you couldn't write C code for GPUs, until eventually hardware manufacturers evolved GPUs to the point where they could support something very much like C. It's not that C is good for GPU programming. It's that hardware manufacturers catered to the C community and eventually threw enough hardware into the mix to make C-on-GPUs a reasonable approach. But the same thing has been happening between languages and hardware since before C was invented. Look at the restrictions on stuff like Fortran IV array indexing, and realize that's because that was the form of the expression that the programmer could look at and understand exactly which addressing mode the indexing operation would use.
ADDITION: Indeed, there's one aspect in which C falls far short compared to other system programming languages like Ada and Forth, and that's in support of dynamically-generated code. The whole C compilation and memory model is a harvard architecture, where the user has no direct control over the program counter's contents, can't generate or even load code on the fly, and in theory has code separate from data in every way. When this assumption is violated, you get one of the most common security flaws in modern systems.