alloca is bad?
Nick Duffek
nsd@redhat.com
Sat Nov 11 13:16:00 GMT 2000
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
More information about the Gdb
mailing list