variables in scopes

[Chen, Brad]

I believe it will be possible in our language to express bad
pointers, regardless of syntax. If we accept this the issue 
becomes: how do we make such problems safe and debuggable.

I believe the memory portal would allow scripts to recover 
safely from the "disaster" scripts Vara suggests below. 
Anticipating Frank's perspective, you might not even need 
the portal, since we already have a special trap handler 
to catch bad pointer dereferences.

I agree with others that asking people to use something 
different than C syntax for navigating C data structures 
from the kernel is the wrong way to go.

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Vara Prasad
Sent: Thursday, April 14, 2005 7:12 AM
To: Jim Keniston
Cc: Frank Ch. Eigler; SystemTAP
Subject: Re: variables in scopes

Jim Keniston wrote:

>On Wed, 2005-04-13 at 15:58, Frank Ch. Eigler wrote:
>
>  
>
> ....
>
>& lvalue
>* pointer
>  
>
I definitely think we will be heading in the wrong direction if we let 
systemtap scripts use full blown "C" pointers directly. It is o.k to let

them traverse datastructures using -> and . constructs but not full 
blown pointers. In my view allowing full pointers is asking for disaster

in terms of the safety of the code. 

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