------- Comment #14 from nigelenki at comcast dot net 2006-07-11 06:25 ------- (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > (In reply to comment #8) > > > > >
... > > > > 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. Uh, ACTUALLY I just pointed out the scenario where the developer has no idea what the end user did; the end user knows he has a problem but that's it; and the developer would have to check the ENTIRE code base blindly if the end user couldn't just tell him "Oh it said it blew up a buffer in f(), whatever that means." In other words I just showed that I saved the developer thousands of man-hours of work. > in fact > the developer still has to debug the program and to see why it is wrong. Yes but now he has a limited number of code paths to go wrong on. > It > might be a misleading to the developer to get where the problem shows up > rather > than where the problem really is caused from. Um, there are only so many code paths that lead you to f(). There's a LOT of code you can cut out of your program now... > Different developers have > different style of debugging so why push one style debuging on them? We're just volunteering more information, not forcing them to use it. Kind of like keeping soda in the fridge. Maybe you don't drink soda, but it's better than keeping nothing so everyone has to drive out to the store when they're thirsty. > > Again the end user does not care why it crashes, they only care if it is > fixed. Right. It crashed, here's the file you asked me to e-mail, fix the damn thing. > 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. And you pick up the "Emergency Phone," and the operator says, "open the panel, there's a number displayed, what does it say?" and you blindly say "37" and they go to an exact panel in an exact room and work backwards from there instead of combing the entire elevator system. > 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). > So, you are saying that software should be dealt with by an end user saying, "I don't know why it broke, fix it;" rather than saying, "I don't know why it broke, it asked me to e-mail you this file. Here, now fix it"? (literal, this is the ENTIRE conversation, you get NO MORE information from the end user on the problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
