Re: Patch for cp-valprint.c

[Tom Tromey <tromey@redhat.com>]

>>>>> "Chris" == Chris Moller <cmoller@redhat.com> writes:

Chris> While working on something else, I found the following:
Chris>    /* FIXME (alloca): unsafe if baseclass is really really large. */
Chris>    gdb_byte *buf = alloca (TYPE_LENGTH (baseclass));

Chris> The attached patch replaces that with a xmalloc/xfree pair.

Please send unidiff or context diffs.

I just put "diff -u -N" into my ~/.cvsrc.  I've never regretted it.

>> buf = xmalloc (TYPE_LENGTH (baseclass));

>> if (buf) {
>> xfree (buf);
>> buf = NULL;

In gdb you can't generally do pairings like this, due to exceptions.
Instead, you must make a cleanup.

Also, you don't need to check the argument to xfree; xfree handles NULL
pointers fine.

Chris> -FAIL: gdb.base/solib-display.exp: after rerun
Chris> -FAIL: gdb.base/solib-display.exp: after rerun (GDB internal error)
Chris> -PASS: gdb.base/solib-display.exp: break 25
Chris> -FAIL: gdb.base/solib-display.exp: continue (GDB internal error)
Chris> -PASS: gdb.base/solib-display.exp: display main_global
Chris> -PASS: gdb.base/solib-display.exp: display a_local
Chris> -PASS: gdb.base/solib-display.exp: display a_static
Chris> -PASS: gdb.base/solib-display.exp: break 25
Chris> -FAIL: gdb.base/solib-display.exp: continue
Chris> +ERROR: Process no longer exists
Chris> +UNRESOLVED: gdb.base/solib-display.exp: after rerun
Chris> +WARNING: remote_expect statement without a default case?!
Chris> +FAIL: gdb.base/solib-display.exp: Can't run to main (3)

Jan has a patch pending for this.

I don't know about the other changes offhand.  Sometimes I re-run the
test suite to see if problems just go away... though I think Jan has put
some work into making this happen less.

Tom