Re: variables in scopes

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Wed, 2005-04-13 at 15:58, Frank Ch. Eigler wrote:

> You may be right.  Have you given consideration to the other
> alternatives I sent to you privately, when you first posted your
> language spec additions?

Yes, I have.  I do prefer the options that I've suggested, but I owe you
specific responses on those suggestions.  I also still need to update
the language description in systemtap.tex per your clarifications.

> 
> 
> > (By the way, I've always been uncomfortable with allowing the use of
> > undeclared variables.  I've heard too many stories about typos in
> > FORTRAN programs yielding disastrous results.)
> 
> Thankfully this is not FORTRAN, we're not controlling a spacecraft,
> and many other languages (including dtrace) get by just fine with such
> properties.

Yes, if it were FORTRAN, I could specify "IMPLICIT NONE" and have the
compiler tell me which names I forgot to declare or (more to the point)
misspelled.  Seriously, I believe that this is a fundamental safety
issue.  We presumably won't crash any spacecraft, but we could crash a
customer's system.  Dtrace doesn't have to worry about this so much
because the user is in a pretty tight straitjacket.

> 
> 
> > > [...]
> > > Note that most of this complication is associated with pointer/struct
> > > traversal.  dtrace's answer to this is to allow typed pointers to be
> > > an additional script-side data type.  Maybe we should consider this.
> 
> Does someone have a response to this part?
> 
>  
> > We really need to bite the bullet and parse full C expressions -- with
> > the gdb parser's help or without it.  [...]
> 
> Not really.  While we may like to have a more compact way of
> performing some operations in target space, that is a long way from
> requiring that "full C" is parsed (casts?  assignments?  function
> calls?  declarations?  control structures? ...).
> 
> It seems to me that we are really missing only a few constructs:
> - referring to variables in target space
> - performing -> . [] on those pointer variables and related names
> Does something else very useful come to mind?

& lvalue
* pointer
functions calls -- to three types of functions:
a) SystemTap auxiliary functions (as currently parsed)
b) C functions in the context of the probed function
c) C functions (set off by yacc/lex escapes such as %% or %{...%}) that
are copied from the .stp file to the module's .c file.

I am certainly willing to limit it to this and then see what we have to
add later.  (c) above should buy us a lot of wiggle room, although it
leaves a hole in semantics checking.

> 
> 
> - FChE

Jim