[Bug other/28328] Stack smash protection non-verbose

["pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-07-11 06:00 -------
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #8)
> > 
> 
> > That is just a simple (obvious) example, you seem to not understand how real
> > code looks like.  You might instead have:
> > 
> > int f(int a, int b)
> > {
> >   int f[10];
> > .....
> >   f[a] = 1;
> > ....
> >   return f[b];
> > }
> > 
> > Where you know that a should be between 0 and 9 but comming into the function
> > it is not, so the value of a is wrong and you have to track down why that is
> > which can be a million lines in execution before calling of f.  This is a stack
> > smashing bug also, yes a less common one than the obvious ones which you showed
> > but it is still going to happen.  The obvious ones are easy to find in an audit
> > of the code, unlike this one.  You can add asserts to the function but that
> > will produce as much useful info as the info you want from the stack smasher. 
> > It is only useful for starting to debug the program, even then you get the
> > information just as quick from the debugger.
> > 
> 
> You make the assumption that I somehow know the bug is in f().  What if I have
> a 64 million line program with several hundred thousand functions like this,
> and the bug is obscure and hard to reproduce?  Where do I start?  How do I know
> the bug is in f()?

Right, you just admitted this is information is only useful when the problem is
obvious which 95% of the time it is not.  So you get only a very small part of
the story from the information which you are requesting to be outputed, in fact
the developer still has to debug the program and to see why it is wrong.  It
might be a misleading to the developer to get where the problem shows up rather
than where the problem really is caused from.  Different developers have
different style of debugging so why push one style debuging on them?

Again the end user does not care why it crashes, they only care if it is fixed.
Think of the issue this way, when you ride on an elevator, and it stops
working, you don't care why, you just care it gets fixed.  This is how software
should be dealt with but really developer's are not held up to that standard
for some reason except in the case where it is life and death can occur (well
technically it can occur any time with real programs because they could cause
someone to have a cesure).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328