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


Other related posts: