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

says...

And how many times are apps, which originally were only going to run on one platform ported later to some unforeseen architecture? I have seen this same play three or four times now. "Everything is 8-bit" Bang. "Everything is 16-bit". Bang. "Everything is 32-bit". Bang.

How many times does it have to happen before we stop saying, "oh, go ahead, buttume away, it won't matter in this case"??

It doesn't need to be a high priority to fix things that are not done wrong in the first place. However, if you make an buttumption that it is not important at development time, and that turns out to be a false buttumption, there will be hell to pay later. This is really a prevention versus "treat the cancer only when you are diagnosed with it" argument.

Until someone figures out a very clever way to use buttumptions about the size of variables for a security exploit. Oops, too late. And there will be more of them that nobody here has thought of yet.

If the program is important enough that you want to review it, then it may be important (in whole or in part) at some later point as well, and that platform might be radically different than the current one. At the very least, take the time to flag it via comment or #ifdef tricks so that if it ever DOES matter, it won't be a needle in a haystack problem to track down. There is certainly no justification for writing new software and not go to such lengths.

It's the only thing. If you do not try to write bulletproof code, then you are not trying hard enough. Your success rate may be imperfect, but you should at least be trying hard. "Ahh, this doesn't matter, I'll be working someplace else before it comes back to haunt me" is a clbuttic trait of nonprofessionals. Don't emulate them.

If you know of the existence of a list of known idioms that have caused problems for programmers in the past, and you don't share the information (far different than making it a priority), then you are doing them a disservice. Further, it may cause you pain down the road as you have to maintain some crap written by originally by one of your students.

There is a huge difference between giving them a bad grade and saying "You know what, this is probably not going to matter for a clbutt project, but in production code, you may want to consider that ...."

The "calloc() issue" could be treated as a single enbreasty as you are doing, or you could consider it a metaphor for an entire clbutt of similar problems that are equally ignored. Individually, they are minor. Collectively, they are the source for all the unstable slop on the market today.

5-10 years ago, anyone having a fit about making buttumptions about int != ptr would have been argued with by the:

"All the world's a 32-bit processor, you old has-been! Don't you know that we'll never need more than 4GB of RAM? What are you smoking?"

crowd.

Ring a bell? I've heard it a few times in the past, with only the numbers changed.

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