Re: loadstring vs load

[Peter Cawley <lua@...>]

On Fri, Dec 10, 2010 at 5:00 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> > It would be possible to deprecate load as well, in favor of loadin.  I
>> > wonder why 5.2-alpha didn't redefine load as such:
>> >
>> >  load (ld [, source [, env, [, mode]]])
>>
>> The way it stands at the moment, load() will accept a bytecode chunk
>> with no upvalues, whereas loadin() will reject a bytecode chunk with
>> no upvalues. I would certainly be in favour of combining load() and
>> loadin(), though I would go for "load (ld [, source [, mode, [,
>> env]]])" as otherwise you couldn't use the default environment with a
>> custom mode parameter (as a nil environment is a valid environment),
>
> Note that 'loadin' does not expose the global environment to a user,
> unlike 'load'. So, it would be safe to allow 'loadin' in a sandbox,
> but unsafe to allow 'load'.
>
> (However, given binary mode, 'loadin' is not safe anyway, so this
> argument is void.)
It is void until someone announces a bytecode verifier, which I should
be doing shortly.

>> and I'd also like the resulting function to accept bytecode chunks
>> with no upvalues.
>
> You mean, even given an environment? Just ignore it in that case?
Yes. If an environment is given, but there are no upvalues, then do
nothing with the environment (which in terms of visible behaviour is
the same as a bytecode chunk which has an _ENV upvalue but never uses
it).