This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: variables in scopes
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