If there's no prototype in scope then C89 will assume malloc() returns int. Let's go back a decade or so to the 16-bit x86 architecture. For the x86 it was possible that you would have 16 bit integers and 32 bit pointers. An int would be returned with a single register and a pointer with two. That alone is a "potentially serious error" if malloc() is assumed to return int because knowing nothing else, it would mangle the pointer to an int and then back to a pointer. But it gets worse. What if the registers used to return a pointer are completely different from the register used to return an int?Quote:
Just even one "potentially serious error" will typcasting malloc() hide?
That's just one processor you say? Okay, same time period think about the Motorola 68000 series. The problem is the same because pointers would be passed using the address registers and integers using the data registers. Both of which were distinct, so the second problem described for the x86 was guaranteed for the 68000.
But that's a long time ago, you say. Come back to the present day and give me a "potentially serious error" Narf, you say. Okay. With the advent of 64-bit systems, it's reasonable to assume that the same problem will arise, except with 32/64 instead of 16/32. In fact, I've heard whispers of that very issue popping up with 64-bit Solaris crashing unexpectedly because stdlib.h wasn't included and malloc() had a cast. But I don't have a 64-bit system, so I can't test it. In my mind the modern problem is all theory and heresay, but I can easily see it happening. That's why I only add the cast after I'm sure that it's both needed and won't hide errors.