Re: parse_expression

"Axel Dörfler" <[email protected]> Sat, 26 May 2007 12:27:57 +0200 CEST
Newsgroups gmane.os.openbeos.kernel.devel
Message-ID <4048758823-BeMail@zon>
"Morgan Howe" <[email protected]> wrote:
> 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 think that's a bit too much - at least I can't see to make use of 
such a powerful language in KDL. But maybe Ingo can deliver some 
striking examples for it :-)

[...]
> > 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]").

The general ideas sound nice, even though they would indeed render the 
call a bit superfluous if it would be automatically applied.
But since it returns numbers anyway, it should still be applied on 
single arguments as needed by the debugger functions (ie. the 
expression parser would also run when the command is not known).
Beyond the temporary variables mentioned by Ingo, I would like to see 
some hardware registers exposed as variables directly (could also be in 
a special namespace, like %eip) - this should not only allow using 
their values, but also to set them to a specific value.

Given the complexity, I would realize this expression parser as a 
module - the default built-in version would simply do a strtoul(string, 
NULL, 0) on everything it gets, while the module version could be much 
more powerful. If it eases development, moving the code into a module 
could also be done as the last step, if you prefer.

Bye,
   Axel.


-------------------------------------------------------------------------
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/