This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Assignment of aggregates in Ada


> From: Paul Hilfinger <hilfingr@gnat.com>
> Date: Fri, 30 Dec 2005 05:13:20 -0500 (EST)
> 
> The following set of changes allows assignments from aggregates in 
> Ada.  I will commit in a few days if there is no objection.

Thanks.

> +  else if (nsyms == 0 || SYMBOL_CLASS (syms[0].sym) != LOC_BLOCK)
> +    {
> +      if (context == NULL)
> +	error ("No file or function \"%s\".", raw_name);
> +      else
> +	error ("No function \"%s\" in specified context.", raw_name);
> +    }
> +  else
> +    {
> +      if (nsyms > 1)
> +	warning ("Function name \"%s\" ambiguous here", raw_name);
> +      return SYMBOL_BLOCK_VALUE (syms[0].sym);
> +    }

Please be sure to include in _() all strings that are messages
displayed to the user.  This is in preparation for GDB's i18n, at some
future date.

> +		error ("Illegal attempt to select from type: \"%s\".", name0.ptr);

Using ``illegal'' in a context that doesn't deal with laws is a no-no
in GNU projects.  ``Invalid'' is the usual replacement.

> Index: gdb/doc/gdb.texinfo

Please include suitable entries for gdb/doc/ChangeLog.

>  @item 
> -There are no record or array aggregates.
> +There is limited support for array and record aggregates.  They are
> +permitted only on the right sides of assignments.  Changing a
> +discriminant's value by means of assignment of an aggregate has an
> +undefined effect if that discriminant is used within the record.
> +However, one can first modify discriminants by directly assigning to
> +them (which normally would not be allowed in Ada), and then performing an
> +aggregate assignment.  @value{GDBN} is very loose about the usual
> +rules concerning aggregates.  You may mention only some of the
> +components of an array or record aggregate; the rest will retain their
> +original values upon assignment.  You may freely use dynamic values as
> +indices in component associations.  You may uses overlapping or
> +redundant component associations, although which component values are
> +assigned in such cases is not defined.

I think an example or two here would help clarify what you are saying.

Also a @cindex entry might be a good idea, for example:

  @cindex array and record aggregates (Ada)

Is the description above the only user-visible effect of these massive
changes?  If not, I'd like to document the rest as well.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]