Thou shalt have no other gods before the ANSI C standard 1378

says...

Technically he was correct, and the good news it is very easy to achieve the same goal, without using calloc and avoid the issue entirely. If it can be fixed, and fixed easily, there doesn't seem much point in trying to defend doing a way that is known to promote bad practice, even if it won't bite you personally.

Further, there is nothing in the standard that prevents a new implementation going on the market having those properties that you feel are so low risk as to be ignorable now. Market dynamics may make it unlikely, of course.

If they aren't coming back, it's probably a good thing, yes.

Looking at the embedded market, if anything is increasing. Amongst PC users, it is widening. Just watch all the hand-wringing that is going on now, but will become more widely heard of soon as all the programmers that made the buttumption that the size of a pointer and the sizeof an int are the same start trying to get their code ported over to 64-bit Windows and Linux. It is going to be ugly. Why? Because people have been essentially using the same arguments you have been making about "all the world's 32-bit" for so long that a lot of software will be broken everywhere you look during the transition.

I agree that it may be exaggerating the severity, but if you know of a way to write code, that doesn't sacrifice requirements in a matter that is immune to a problem, using some other method that is suspect to it is at least suboptimal, if not outright wrong.

Now, if it causes your software to run 35% slower, then it might be a (documented) decision to knowingly not correct it. Most of the issues we have been talking about can be handled with far less pain than that, if they can be measured at all.

-- Randy Howard (2reply remove FOOBAR) "Making it hard to do stupid things often makes it hard to do smart ones too." -- Andrew Koenig