[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Method dereferencing protection
- From: Mark Hamburg <mhamburg@...>
- Date: Thu, 14 Aug 2003 00:35:56 -0700
One thing that bites me occasionally when writing Lua code is the obj:method
v. obj.method detail. When writing pure Lua code, these sort of bugs
generally reveal themselves pretty quickly and are only moderately difficult
to track down and fix. When implementing userdata in C, however, I find I
either need to have a pretty strong way to check that I've gotten back the
correct userdata type or things can go down pretty hard. Doing the strong
checking slows stuff down, however, and since I'd like to have stuff be
scriptable by end users I don't really have the option of shipping a debug
version or of just letting it crash.
Looking at the VM and the compiler, I'm guessing that the colon always goes
through OP_SELF and essentially nothing else does? Is this correct?
If so, could one teach OP_SELF to look for another metatable entry -- e.g.,
__self -- in addition to __index? That way, one could put the "I only want
to be used in a colon-operator call" C functions in the __self table and be
assured that they were being used with the right datatype?
Or is there more that would need to be done? (I know that TM_SELF would
probably need the same optimizations as TM_INDEX.)
Is this a reasonable proposal?