On Tuesday, November 02, 2010 11:31:03 pm Tom Tromey wrote:
> >>>>> "Ken" == Ken Werner <ken@linux.vnet.ibm.com> writes:
> Ken> Index: gdb/c-valprint.c
> Ken> ===================================================================
> Ken> RCS file: /cvs/src/src/gdb/c-valprint.c,v
> Ken> retrieving revision 1.74
> Ken> diff -p -u -r1.74 c-valprint.c
> Ken> --- gdb/c-valprint.c	15 Oct 2010 18:54:12 -0000	1.74
> Ken> +++ gdb/c-valprint.c	19 Oct 2010 12:15:30 -0000
> Ken> @@ -171,8 +171,13 @@ c_val_print (struct type *type, const gd
> Ken>        elttype = check_typedef (unresolved_elttype);
> Ken>        if (TYPE_LENGTH (type) > 0 && TYPE_LENGTH (unresolved_elttype)
> > 0) Ken>  	{
> Ken> +          LONGEST low_bound, high_bound;
> Ken> +
> Ken> +          if (!get_array_bounds(type, &low_bound, &high_bound))
> 
> Missing space before open paren.

Fixed.

> Ken> +            error (_("Could not determine the array high bound"));
> Ken> +
> Ken>  	  eltlen = TYPE_LENGTH (elttype);
> Ken> -	  len = TYPE_LENGTH (type) / eltlen;
> Ken> +	  len = high_bound - low_bound + 1;
> 
> I guess it is ok to use 'eltlen' elsewhere in the function because it is
> only the array's overall size which is "weird" -- the element size is
> still correct.  (Since we don't implement the DWARF stride stuff...)

Yes, that is also my understanding.

> The patch is ok with the above nit fixed.

Thanks. I've checked in the version below:
http://sourceware.org/ml/gdb-cvs/2010-11/msg00014.html

> I wonder whether f-valprint.c also needs an update.

The f77_create_arrayprint_offset_tbl function seems to setup the 
f77_array_offset_tbl with the appropriate lengths.

Regards
Ken