Re: NILifiying user variables

[LEGO <luis.ontanon@...>]

On 2/8/06, David Given <dg@cowlark.com> 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
> |  dg@cowlark.com    | coming to a middle." --- Firefly, _Our Mrs.
> | (dg@tao-group.com) | Reynolds_
> +- www.cowlark.com --+
>
>
>


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