On Fri, Apr 06, 2007 at 11:50:01AM +0100, Rob Quill wrote:
> >int i = 0;
> >int j = 2;
> >int n = CalculateSomething( j, &i );
> >int k = 3;
>
> I don't really understand, because the problem remains that if you
> break before int n... and do print n you get a value, whereas you
> should get an error saying the variable is not in scope.
The current behavior is that you will get a random value. As you say, it
could be fixed. But it's relatively minor, and fixing it has a cost (the
debug information must increase in size). If someone wants to put
together a patch to implement the extra scope directives AND reports
actual measurements on the size increase that results (for 2-3 large FLOSS
C++ programs, for example) AND the bloat created is small, it could be a
useful feature.
It could even help with a case that has gotten me into trouble. Consider
Foo foo = functionReturningFoo();
Now, let's say that Foo is a complex object containing pointers, and
there's a member function Foo::p() const that pretty-prints Foo on
the standard error, put there explicitly for calling in debuggers.
Suppose I mistakenly put the breakpoint on this line and tell gdb
(gdb) call foo.p()
But foo has not yet initialized, it is random stack junk, so Foo::p
is likely to crash the application. If, instead, gdb were to report
that foo doesn't exist (or use a foo from an outer scope), this source
of debugger crashes would be eliminated.
Anyway, I think it's up to the proponents of your idea to provide
a patch and make the case for its conclusion. If the size increase
is insignificant, no problem.
