public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/doco] set varsize-limit: New GDB setting for maximum dynamic object size
Date: Thu, 22 Feb 2018 15:47:00 -0000	[thread overview]
Message-ID: <83efld58mu.fsf@gnu.org> (raw)
In-Reply-To: <1519312873-6307-1-git-send-email-brobecker@adacore.com> (message	from Joel Brobecker on Thu, 22 Feb 2018 10:21:13 -0500)

> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 22 Feb 2018 10:21:13 -0500
> 
> +* New commands
> +
> +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?

> +  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".

> +@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 ...".

>                                                When this limit is set
> +to @code{unlimited}, there is no limit.

I'd rephrase

  Setting @var{size} to @code{unlimited} removes the size limitations.

> +The purpose of having such a limit is to prevent @value{GDBN} from
> +trying to grab enormous chunks of virtual memory when asked to evaluate
> +a quantity whose bounds have been corrupted or have not yet been fully
> +initialized.  The limit applies to the results of some subexpressions
> +as well as to complete expressions.  For example, an expression denoting
> +a simple integer component, such as @code{x.y.z}, may fail if the size of
> +@var{x.y} is dynamic and exceeds @var{size}.  On the other hand,
> +@value{GDBN} is sometimes clever; the expression @code{A(i)}, where
> +@var{A} is an array variable with non-constant size, will generally
> +succeed regardless of the bounds on @var{A}, as long as the component
> +size is less than @var{size}.

All of the symbols except "size" should have the @code markup here,
not @var.

The documentation parts are okay with these nits fixed.

Thanks.

  reply	other threads:[~2018-02-22 15:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 15:21 Joel Brobecker
2018-02-22 15:47 ` Eli Zaretskii [this message]
2018-02-23  4:59   ` Joel Brobecker
2018-02-23  7:11     ` Eli Zaretskii
2018-02-23 10:21       ` Joel Brobecker
2018-02-23 13:56         ` Eli Zaretskii
2018-03-27 14:23         ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83efld58mu.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).