Hi Eli, Thanks for the review. Sometimes, I wonder what we would do without your help! > > +set|show varsize-limit > > + This new setting allows the user to control the maximum size of Ada > > + objects being printing when those objects have a dynamic type, > ^^^^^^^^ > "printed", I guess? Yes, absolutely. Corrected in the attached version. > > > + add_setshow_uinteger_cmd ("varsize-limit", class_support, > > + &varsize_limit, _("\ > > +Set the maximum number of bytes allowed in a dynamic-sized object."), _("\ > > +Show the maximum number of bytes allowed in a dynamic-sized object."), _("\ > > +Attempts to access an object whose size is not a compile-time constant\n\ > > +and exceeds this limit will cause an error."), > > This is okay, but I wonder if "varsize" is a good name. The > explanatory text you've written doesn't talk of any "variables". It was before my time (so more than 15 years ago!), but I think that "var" (for variable) is the adjective, rather than the noun. We could discuss better names, but as I was trying to say towards the end of my initial email, I am trying to avoid that (if possible!), to avoid having users who need to transition between the old setting's name, and the new one. Believe it or not, I'm still hearing from users who are still stuck using "begin" (the name AdaCore chose to start the program and stop at the first line of the main subprogram -- this command was eventually contributed and the name chosen was "start"). I get the same regular grief regarding "break exception", which was changed to "catch exception" when contributed as well. Of course, if we come up with a name that is so much better, I will sure those impacted have a transition path. In this case, I think the name of the command is not all that bad. Also, error message raised when we exceed that limit gives a hint towards the setting that controls it: void ada_ensure_varsize_limit (const struct type *type) { if (TYPE_LENGTH (type) > varsize_limit) error (_("object size is larger than varsize-limit")); } So I would like to argue for us to keep the current name if people are OK with that. > > +@item set varsize-limit @var{size} > > +Limit the size of the types of objects to @var{size} bytes when those > > +sizes are computed from run-time quantities. > > Is this only for printing, or is this more general? > > in any case, "limit the size of types of objects" is ambiguous (the > "types" part confuses things), and doesn't really tell what does this > limit. If it's only about printing, then let's say "don't print > objects whose size exceeds ...". If it isn't limited to printing, how > about "don't attempt to evaluate objects ...". > > > +to @code{unlimited}, there is no limit. > > I'd rephrase > > Setting @var{size} to @code{unlimited} removes the size limitations. Good suggestions. Thanks! New version attched. gdb/ChangeLog * NEWS: Add entry describing new "set|show varsize-limit" command. * ada-lang.c (_initialize_ada_language): Add "set/show varsize-limit" command. * printcmd.c (_initialize_printcmd): Add "set var" alias of "set variable". gdb/doc/ChangeLog: * gdb.texinfo (Ada Settings): New subsubsection. gdb/testsuite/ChangeLog: * gdb.ada/varsize_limit: New testcase. Tested on x86_64-linux. Thank you, -- Joel