Re: RFC: fix PR c++/9197

[Doug Evans <dje at google dot com>]

On Fri, Mar 8, 2013 at 12:16 PM, Tom Tromey <tromey@redhat.com> wrote:
> Jan> I was briefly checking the code and while sometimes one must change
> Jan> also the callers / callers of callers etc. struct type * -> struct
> Jan> value * it should not be such a problem.
>
> Today I tried an approach like this.  I added a new "lval_type" and
> changed a lot of code to use it.
>
> I like this, I think it is pretty clean.  However the patch quickly grew
> very large, and I discovered that plenty of code exists that violates
> the reason I rejected my first approach:
>
> Tom> However, I'm no longer convinced it is safe, seeing how many other
> Tom> paths in eval.c avoid even memory reads for the
> Tom> EVAL_AVOID_SIDE_EFFECTS case.
>
> You can easily see memory reads using any path through binop_promote.
> For example if you have "short s; char c;", then "ptype s+c" will read
> memory.  There are many of these.
>
> So now I'm leaning toward putting in my original fix.

For my own education, setting aside however broken gdb currently is,
what's the right answer?
IOW, how is ptype *defined* to work?
And, most importantly, is it possible to complete any missing pieces
of the definition (or at least write down our current best
understanding) so there's no more guesswork involved in the future?

One needn't think of memory mapped devices, one can just play with
mapped/unmapped memory (e.g. some memory may get unmapped after having
been mapped) or bad pointers.  Also,  is "ptype s+c" materially
different from "ptype *sptr+*cptr" ? (and do we want to impose any
distinction on the user?)
[Plus s and c could be in formerly mapped memory - should ptype s+c still work?]

I'm not sure I have a strong feeling on whether ptype should use
EVAL_NO_SIDE_EFFECTS or not, but if it should it feels like it should
be consistent.

Also, maybe have an option to ptype that specifies side-effects or not?
Interestingly, the online help of ptype says nothing about
expressions, need to fix that.

And now I'm wondering if we need a mechanism to distinguish the
ambiguity if "s" is a type and an expression.
E.g.
class s { public: int x; };
int s;

Also, for reference sake,
(gdb) p s
Attempt to use a type name as an expression

How do I print s the variable?  [maybe there's a way but it escapes me]