PLEX86  x86- Virtual Machine (VM) Program
 CVS  |  Mailing List  |  Download  |  Newsgroups

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


Your Ad Here

Your Ad Here

Randy Howard

It's only *wrong* if your requirements (explicit or implicit) require you to be portable to platforms where this idiom doesn't work. For many apps, this just isn't a requirement.

Thou shalt have no other gods before the ANSI C standard 1382
Randy Howard And sometimes that kind of decision is rational and makes economic sense. Let me give you an example. Suppose that it costs X to make your...

I don't know. I think we need to keep our perspective about this. For most code, this isn't *wrong* or *a security hole*, it is just a way in which the code isn't portable to obscure platforms (that maybe no one was ever planning on porting this code to anyway). In the grand scheme of things, how high a priority is it to fix this? From a security point of view, it is way way down the list, for most apps.

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...

Probably we should distinguish between reading code vs writing new code. When reading existing code, there is little point in getting excited about finding such a bug, and there is little point in spending a lot of effort on looking for such bugs, unless your evaluation platforms include weird platforms where calloc() doesn't work as expected. When reading code, I'd go so far as to say "no big deal"; if we can't answer the "who cares?" question, we've likely got bigger fish to fry.

When writing new code, maybe there is a better argument for avoiding the calloc() idiom. If it is easy and doesn't cost anything, hey, why not. Getting in the habit of writing code that is as bulletproof as possible isn't such a bad thing. But, would I put it high on the list of priorities to teach programmers who are writing security-critical code? Not a chance. Would I castigate programmers who slip up and use calloc()? Naah. If this is the biggest mistake they are making, then yeah, it is maybe worth pointing out alternative coding styles, sure.

Thou shalt have no other gods before the ANSI C standard 1381
To this I don't totally agree. In my experience, if some code needs 32-bit ints and...

Compared to all the other enormous considerations facing anyone writing security-critical code, the calloc() issue strikes me as pretty minor, relatively speaking.

No, that's not the same. I think you are reacting to the mere idea of making any buttumptions whatsoever. But think this through a little more carefully. Some buttumptions may be totally unreasonable, but other buttumptions might be entirely reasonable.



Your Ad Here

List | Previous | Next

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

Alt Folklore Computers from Newsgroups

The #1 Usenet Provider on the Internet

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