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: [rfc][08/37] Eliminate builtin_type_ macros: Make pointer arithmetic explicit


On Tue, Sep 02, 2008 at 11:47:08PM +0200, Ulrich Weigand wrote:
> Lets put the question differently:  Why should the generic "add" routine
> of a debugger supporting many languages have hard-coded semantics that
> are specific to C (and in fact, the C ABI on a specific platform)?
> 
> I was trying to make the "value_*" routines be as much as possible
> language- and architecture-independent, and push language- and
> architecture-specific semantics up to higher layers.  (In this case,
> the expression evaluator.  In fact, I might like it even better if 
> expressions themselves were also language-agnostic, and all the
> language-specific semantics were encoded explicitly into different
> operand codes by the parsers ...)

Yes, that would be nice - but I think we'd need a different
parsing system then; for instance, to do C++ overloading at the right
time.

> As to your question: when replacing uses of value_add, every caller
> *knew* whether the arguments were pointers or scalars (exept for the
> generic expression evaluator, of course).  GDB-internal uses do not
> really assume the C-specific overloading of the "+" operator ...

OK, that's good enough for me.  I agree it would be nice to define
what the value operators do.  We'll be exposing them to Python, and
I want to be able to document sanely in the manual what happens if you
add an integer and a pointer :-)

-- 
Daniel Jacobowitz
CodeSourcery


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