lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I think that having a data representation language which is executable is extremely dangerous and I would never use it unless the "data" came from an extremely trusted source. Basically myself. Even if I had written my own interpreter for it. This is one case where data should definitely be data and nothing else.

Robert

----- Original Message -----
> From: "steve donovan" <steve.j.donovan@gmail.com>
> To: "Lua mailing list" <lua-l@lists.lua.org>
> Sent: Monday, 7 January, 2013 9:58:06 AM
> Subject: Re: Is Lua used as a data representation language?
> 
> On Sun, Jan 6, 2013 at 12:55 AM, Javier Guerra Giraldez
> <javier@guerrag.com> wrote:
> > or against, if you want to prove your configs always terminate.
> 
> Yep, we have to go to some trouble to ensure that untrusted Lua is
> not harmful.
> 
> Whereas LON/LTIN is deliberately very restricted, and would have a
> small C parser that C programs could use without Lua itself.
> 
> I like to think of APIs in terms of what the programmer sees.  So I'm
> free to dream up a hypothetical library 'john' (LTIN John, you see
> ;))
> 
> So with this data
> 
> {
>   names = {'Janes','Mary'},
>   ages = {25,32}
> }
> 
> it goes like this:
> 
> John *j = john_parse(ltin_text);
> char *err = NULL;
> char **strings;
> double *ages;
> int n1 = john_get_tag_string_array(j,"names",&strings,&err);
> int n2 = john_get_tag_double_array(j,"ages",&ages,&err);
> if (err != NULL) {  // conversion/type error
>    fprintf(stderr,"error: %s\n",err);
>   return;
> }
> if (n1 != n2) { // logical error
>   fprintf(stderr,"error: names and ages array not the same size\n");
>   return;
> }
> 
> Of course, lots of details about allocation strategy and whether
> get_tag should take key paths like "foo.bar", but that's the basic
> idea.
> 
> Currently, we're just playing ping-pong, knocking the ball lazily
> across the room. Either we'll get bored or someone will give the ball
> a good whack.
> 
> steve d.
> 
>