parse_expression

Hello,

I'm thinking about implementing the parse_expression call for the KDL,
and so Ingo thought I should run it past everyone in the list to see
what capabilities they would like from this function.  First, here are
Ingo's requests:

> Personally I'd even consider a basic procedural language -- including if and
> loop constructs as well as command invocation from within expressions.
>
> I would definitely add a return value semantics to the debugger commands,
> i.e. something like a set_debugger_command_return_value(int64) function a
> debugger command can call (maybe defaulting to 0, if not called) and a
> default variable to access the value.
>
> Other than that, built-in memory access (like the unary "*" C operator,
> probably with different syntax to allow for accessing 1/2/4/8 byte values)
> might be nice.
>
> Regarding the syntax, I was thinking of brackets or braces to mark an
> expression. This would actually make the parse_expression() function a little
> bit superfluous, since the evaluation could be done before a debugger command
> is invoked. Variables would be standard C identifiers, probably with a
> stricter length restriction (maybe around 20-32 chars). Operations should be
> standard arithmetics, i.e. +-*/%<<>>&|~. Decimal, hex, binary and maybe octal
> numbers should be supported. It would also be handy to process expressions
> outside of a command invocation (e.g. just type "[address = address +
> length]").
>
> Since 64 bit architectures are already around, variables should be 64 bit
> wide. An initial assignment should declare a variable, and there should be
> some way to explicitely undeclare it again. I believe, it would be great, if
> a debugger command could set temporary variables (in a special name space,
> e.g. starting with "_") that are declared until the next command is invoked.
> E.g. the "sc" command could set "_ebp", "_eip", etc., so that after a "sc
> 0x17" one could type "db [_ebp] 32" or save interesting values in permanent
> variables ("[lastFrame = _ebp]", "[crashAddr = _eip]").
>
> Well, these are my first thought on the topic. Others may have other and
> better ideas.

And so, I would like to ask anyone else who has any thoughts,
comments, or requests to speak up so that I can get a general idea of
what everyone needs.

Regards,
Morgan

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/