Re: [rfc] expose gdb values to python

[Daniel Jacobowitz <drow@false.org>]

On Fri, Sep 19, 2008 at 04:39:12PM -0600, Tom Tromey wrote:
> Thiago> I believe it's better to avoid using current_language, right?
> Thiago> I don't think there's a way to get a sensible language_defn to
> Thiago> use here, so my only idea is to add an element to struct value
> Thiago> which holds the language associated with the value. This
> Thiago> element would be filled at the moment the value is created.
> 
> My first reaction to this was "no way".  But, I couldn't think of a
> concrete case where this would have bad results -- especially provided
> we restrict use of the language field to stringifying the value.

This seems iffy.  A value's just a value - how it's printed depends on
how it's used, not how it was created.  e.g. if two languages had
different number formatting, "print $1" should generate different
results based on the current language.

So what the right language is may depend on the context.

> There are some intermediate ideas, too, like allowing the invisible
> approach only when the field name is unique; or we could define the
> search order.  (It is tempting to use the language's rules, but I
> suspect this might be too tricky to get right.)

Why isn't this the same as for expression evaluation in GDB today?
That does follow the language rules (and fail, in some cases).

I'm not sure we really need length to work, but I haven't spent much
time looking at it.  If we don't, I'd rather it failed always than
intermittently.

-- 
Daniel Jacobowitz
CodeSourcery