Re: alloca is bad?

[Nick Duffek <nsd at redhat dot com>]

Do we have a standard way to decide issues like this?  Perhaps there
should be a group of GDB developers who vote on coding standards and other
contentious technical issues.

On 11-Nov-2000, Fernando Nasser wrote:

>Meomory leak -> small problem, easy to identify the culprit.

>Stack corruption -> big problem, difficult to know even where to start.

It's not memory leaks vs. stack corruption, it's memory leaks + heap
corruption + coding errors vs. stack corruption.

Pseudo-mathematically, the pro-alloca claim is:

  memory leaks + heap corruption + coding errors > stack corruption

where ">" means "is worse than".  If heap corruption == stack corruption,
then they cancel out and the above becomes:

  memory leaks + coding errors > 0

which is obviously true.  So, is it true that heap corruption == stack
corruption?  Memory corruption badness can be quantified as:

  (likelihood of occurrence) * (difficulty in tracking down)

If we establish appropriate guidelines on maximum alloca sizes, then stack
corruption is no more likely than heap corruption, so roughly:

  heap corruption likelihood == stack corruption likelihood

You claim that stack corruption is harder to track down than heap
corruption.  I claim the opposite, based on personal experience and
arguments presented elsewhere in this thread.

But until someone posts hard numbers quantifying this question, I think
such claims aren't meaningful, so for now:

  heap corruption difficulty == stack corruption difficulty

which completes the "proof" of the original claim.  :-)

Incidentally, I disagree with:

>Meomory leak -> small problem, easy to identify the culprit.

When a leak is small, it's insidious.  GDB gets a bit more sluggish, but
not enough that anyone thinks to check for a memory leak.  Therefore,
leaks can go undetected for years.  Total GDB user time wasted:

  (tiny slowdown) * (entire GDB user population) * (years)

By contrast, memory corruption usually gets detected and fixed pretty
quickly.  Total GDB user time wasted:

  (time to revert to previous version) *
    (the few GDB users who found the corruption before it was fixed)

It wouldn't surprise me if the former were bigger than the latter.

Nick