Re: Features for the facilitation of sandbox construction
- From: Sean Conner <sean@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 3 Aug 2012 20:26:36 -0400
It was thus said that the Great Philipp Kutin once stated:
> Hello,
>
> Since I began to use LuaJIT to create a new scripting system for the
> game port that I co-maintain, there has always been a recurrent
> problem that concerns the user/internal code divide, and how to access
> stuff from the latter while restricting it from the former. For
> example, consider a stripped down "wall" struct as it appears in our
> code:
>
> typedef struct
> {
> int32_t x, y;
> int16_t point2; // walls hold only one point for us, this is the
> index of the second one
> int16_t picnum; // must be in [0 .. MAXTILES-1]
> int8_t shade;
> } walltype;
>
> The first four members have certain restrictions and must not be
> modified arbitrarily, so we'd make them 'const' in our FFI C
> declaration, thereby losing the ability to modify them from trusted,
> internal code. Another option would be to unrestrict the struct and
> write accessor functions for each member (which are many more), but
> then we'd have to hide the actual struct from user code, and
> syntactically it'll look very awkward.
What's wrong with declaring two structures, the public one for user code:
typedef struct
{
const int32_t x;
const int32_t y;
const int16_t point2;
const int16_t picnum;
int8_t shade;
} walltype;
and one for trusted code:
typedef struct
{
int32_t x;
int32_t y;
int16_t point2;
int16_t picnum;
int8_t shade;
} walltype_i;
The trusted code can cast any walltype variables to walltype_i variables
(or a pair of functions to safely convert one to the other). Or am I missing
something?
-spc
Other related posts:
