NILifiying user variables

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NILifiying user variables

lego-2
Hello,

I'm in the process to embed Lua into ethereal http://www.ethereal.com.

Now, I have a problem.

While scanning a packet a "packet_buffer" object is passed to the
user's dissection function. In ethereal the lifetime of this object is
that of the packet been currently analyzed. The pointer to the
underlying C object is not going to be valid after the function has
returned. If an user (the lua function) saves a copy of this variable
in a global that variable will surely be unusable.

This variables are accessed very often while analyzing packets so
having to either copy them or create and destroy a container that
keeps track o the frame number they come from would sensibly slow down
operation.

What I wondered is whether there is a (relatively fast) way I can make
sure that these variables are either not copied into global variables
(while still giving access to the global environment) or that these
refernces are nil-ified after the dissection/inspection of the current
packet has been done.

Thanks,

Luis

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
Reply | Threaded
Open this post in threaded view
|

Re: NILifiying user variables

David Given
On Wednesday 08 February 2006 12:34, LEGO wrote:
[...]
> This variables are accessed very often while analyzing packets so
> having to either copy them or create and destroy a container that
> keeps track o the frame number they come from would sensibly slow down
> operation.

Ha!

I have *exactly* this issue with something I'm doing. My solution is to zap
the content of the userdata to make the variable unusable one the callback
has returned.

callback(void* ptr)
{
        userdata* u = createuserdata()
        *u = ptr;

        ...call lua...
       
        *u = NULL;
}

My Lua bindings for accessing the underlying structure then have to check to
ensure that the userdata is valid before dereferencing it. If it's not valid,
it call luaL_error().

This should ensure that if anyone keeps one of these structures longer than
they're supposed to, it should have no harmful effects (other than causing
their code to break, which it would anyway). Does this approach work for you?

--
+- David Given --McQ-+ "My days of taking you seriously are certainly
|  [hidden email]    | coming to a middle." --- Firefly, _Our Mrs.
| ([hidden email]) | Reynolds_
+- www.cowlark.com --+

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NILifiying user variables

lego-2
On 2/8/06, David Given <[hidden email]> wrote:

> On Wednesday 08 February 2006 12:34, LEGO wrote:
> [...]
> > This variables are accessed very often while analyzing packets so
> > having to either copy them or create and destroy a container that
> > keeps track o the frame number they come from would sensibly slow down
> > operation.
>
> Ha!
>
> I have *exactly* this issue with something I'm doing. My solution is to zap
> the content of the userdata to make the variable unusable one the callback
> has returned.
>
> callback(void* ptr)
> {
>         userdata* u = createuserdata()
>         *u = ptr;
>
>         ...call lua...
>
>         *u = NULL;
> }
>
> My Lua bindings for accessing the underlying structure then have to check to
> ensure that the userdata is valid before dereferencing it. If it's not valid,
> it call luaL_error().
>
> This should ensure that if anyone keeps one of these structures longer than
> they're supposed to, it should have no harmful effects (other than causing
> their code to break, which it would anyway). Does this approach work for you?

Yes, that would certainly be faster than encapsulating the object in
another structure and keeping track of the frame_number at every
invocation.

As far as ethereal does not crash I think it's the user's business to
make sure its code work.

While it would be lovely if the processor automagically got the right
pointer for me realistically I simply cannot expect the system to
avoid a bus error when I dereference a NULL pointer, that's the nature
of things and I have to accept it.

Thanks.

> --
> +- David Given --McQ-+ "My days of taking you seriously are certainly
> |  [hidden email]    | coming to a middle." --- Firefly, _Our Mrs.
> | ([hidden email]) | Reynolds_
> +- www.cowlark.com --+
>
>
>


--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan