lua-users home
lua-l archive

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



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.