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: [RFA] print arrays with indexes


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


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