Re: Byte Code and Backwards Compatibility (was Re: Explicitly triggering the Garbage Collector)

[Rici Lake <lua@...>]

On 7-Aug-05, at 1:42 PM, Uli Kusterer wrote:

> Actually, for my uses it would really be an advantage. I'm not saying 
> I want to be able to run code compiled by a newer Lua version in the 
> older one, but the other way round would be handy: If I compile Lua 
> Code with 5.0, I'd really like if I could feed that file into 5.1 and 
> still have it work like before.

Yes, that is understandable. But it would make the VM implementation 
much less efficient if it were constantly checking for version, and VM 
efficiency is the key to get a VM-compiled language to execute rapidly. 
(Well, leaving aside the possibility of JIT compilers :) )

>  The problem in my case is that the byte code wouldn't be part of my 
> application. My app is simply an engine, which runs compiled Lua 
> scripts and provides a runtime environment (certain object hierarchies 
> and a GUI) for them. It would be a disadvantage for users of this app 
> if they had to recompile the scripts for each new version of the 
> engine.

You can tell which version of the engine compiled byte code has been 
compiled for. Or, better said, the byte code loader can tell. So you 
could do something like this: try loading the compiled script; if it 
fails, then recompile it.

>  Yeah, just making them ZIP files wouldn't be very safe. I won't even 
> try to deter anyone hell-bent on getting the data out of the file, but 
> it's not really very desirable to make it as easy as just changing the 
> suffix to .gz and suddenly the files unpack before your eyes...

Very true. I wasn't quite suggesting that; rather, that you created C 
"programs" that look something like:

const char zipped_prog[] = {45, 234, 67, 0, 1, ...};
... code to decompress zipped_prog and feed it into the Lua compiler.

The compiled object code for that C file would not be quite as easy to 
decompress as simply changing its name from zipped_prog.a to 
zipped_prog.gz :) But obviously it would be fairly easy to decompress 
it. You could make it slightly harder to find the compressed string if 
you synthesized the gzip header rather than just putting it into the 
string, etc., but in the end it is not a security mechanism.