Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] print arrays with indexes
Date: Tue, 20 Sep 2005 07:31:00 -0000	[thread overview]
Message-ID: <20050920073058.GR2496@adacore.com> (raw)
In-Reply-To: <uirwy5egh.fsf@gnu.org>

Now that Mark and Eli have commented as well, it seems that the majority
of us prefer a feature controled by a single knob. Eli seems ok with a
two-knob approach, but doesn't seemed resistant to the one-knob either,
so I'll conclude that the single-know approach is what we are going to
implement. Fair enough?

In terms of the actual specifics of that control, I think we have a
general agreement that a user should be able to use "on" and "off"
keywords to set it. So we need a way to provide an "on/off/threashold"
interface. So far, I think we are ok with this approach.

Something we haven't really formally decided though, is the significance
of the threashold. Is it:

  1. If array size > threshold, then print indexes
  2. If array size < threshold, then print indexes

(you can replace the strict comparison operator by <= or >=, to be
discussed too).

Now, the sticky part: How to implement this new interface.

I'll argue that it's best to implement something new. I don't like
hijacking an old interface to unsigned integer and adding some aliases
to a couple of values. My reasoning is that saying that OFF is an alias
for UINT_MAX will make sense for certain cases while it actually won't
for other cases. Actually, which value to use for OFF will depend on
the what the threashold actually means.

Short of implemeting something new, I can suggest enhancing the API
for unsigned integer settings, by adding a way to provide aliases and
their corresponding values. Drawback, we will probably have to make
quite a fair number of changes, at all the places where these routines
are already used.

I vote for a new API.

I think we should also review the usage of the current ones, probably
cleanup a bit some of the ones that were on the road to obsolescence
(IIRC), maybe rationalize a bit more our API if needed, and add some
documentation. But that should be a separate thread. I don't think I
will be able to handle all of this, but I can certainly help.

-- 
Joel


  reply	other threads:[~2005-09-20  7:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 20:20 [RFC/RFA] " Joel Brobecker
2005-09-06 20:57 ` Daniel Jacobowitz
2005-09-07  5:40   ` Joel Brobecker
2005-09-07 13:23     ` Daniel Jacobowitz
2005-09-07 20:24       ` Joel Brobecker
2005-09-14 17:13         ` [RFA] " Joel Brobecker
2005-09-17 20:49           ` Daniel Jacobowitz
2005-09-17 21:51             ` Joel Brobecker
2005-09-17 22:07               ` Daniel Jacobowitz
2005-09-18  3:37               ` Eli Zaretskii
2005-09-18  3:46                 ` Daniel Jacobowitz
2005-09-18  5:41                   ` Joel Brobecker
2005-09-18 19:08                     ` Eli Zaretskii
2005-09-18 19:19                       ` Daniel Jacobowitz
2005-09-18 20:05                         ` Eli Zaretskii
2005-09-20  7:31                           ` Joel Brobecker [this message]
2005-09-20 19:18                             ` Eli Zaretskii
2005-09-20 19:31                               ` Joel Brobecker
2005-09-20 19:33                                 ` Daniel Jacobowitz
2005-09-20 19:39                                   ` Joel Brobecker
2005-09-21  3:44                                     ` Eli Zaretskii
2005-09-22 16:47                                     ` Joel Brobecker
2005-09-26  1:23                                       ` Daniel Jacobowitz
2005-09-27  1:04                                         ` Joel Brobecker
2005-10-02 22:42                                           ` Daniel Jacobowitz
2005-10-03  6:17                                             ` Joel Brobecker
2005-10-03 15:50                                               ` Daniel Jacobowitz
2005-10-03 21:23                                                 ` Joel Brobecker
2005-10-04  7:02                                               ` Joel Brobecker
2005-10-04  7:41                                                 ` Joel Brobecker
2005-09-21  3:44                                 ` Eli Zaretskii
2005-09-18  8:53                 ` Mark Kettenis
2005-09-18 19:10                   ` Eli Zaretskii
2005-09-07 20:39       ` [RFC/RFA] " Jim Blandy
2005-09-07 21:41         ` Joel Brobecker
2005-09-09 19:14           ` Jim Blandy
2005-09-06 21:45 ` Jim Blandy

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=20050920073058.GR2496@adacore.com \
    --to=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /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