This is a small module that aims to make it easier to write code
in a Lua-5.3-style that is compatible with Lua 5.1, Lua 5.2, and Lua
5.3. This does not make Lua 5.2 (or even Lua 5.1) entirely
compatible with Lua 5.3, but it brings the API closer to that of Lua
5.3.
It includes:
For writing Lua: The Lua module compat53, which can be require'd
from Lua scripts and run in Lua 5.1, 5.2, and 5.3, including a
backport of the utf8 module, the 5.3 table module, and the
string packing functions straight from the Lua 5.3 sources.
For writing C: A C header and file which can be linked to your
Lua module written in C, providing some functions from the C API
of Lua 5.3 that do not exist in Lua 5.2 or 5.1, making it easier to
write C code that compiles with all three versions of liblua.
How to use it
Lua module
require("compat53")
compat53 makes changes to your global environment and does not return
a meaningful return value, so the usual idiom of storing the return of
require in a local variable makes no sense.
When run under Lua 5.3+, this module does nothing.
When run under Lua 5.2 or 5.1, it replaces some of your standard
functions and adds new ones to bring your environment closer to that
of Lua 5.3. It also tries to load the backported utf8, table, and
string packing modules automatically. If unsuccessful, pure Lua
versions of the new table functions are used as a fallback, and
Roberto's struct library is tried for string packing.
Lua submodules
local _ENV =require("compat53.module")
if setfenv thensetfenv(1, _ENV) end
The compat53.module module does not modify the global environment,
and so it is safe to use in modules without affecting other Lua files.
It is supposed to be set as the current environment (see above), i.e.
cherry picking individual functions from this module is expressly
not supported!). Not all features are available when using this
module (e.g. yieldable (x)pcall support, string/file methods, etc.),
so it is recommended to use plain require("compat53") whenever
possible.
C code
There are two ways of adding the C API compatibility functions/macros to
your project:
If COMPAT53_PREFIX is not#defined, compat-5.3.h#includes
compat-5.3.c, and all functions are made static. You don't have to
compile/link/add compat-5.3.c yourself. This is useful for one-file
projects.
If COMPAT53_PREFIX is #defined, all exported functions are renamed
behind the scenes using this prefix to avoid linker conflicts with other
code using this package. This doesn't change the way you call the
compatibility functions in your code. You have to compile and link
compat-5.3.c to your project yourself. You can change the way the
functions are exported using the COMPAT53_API macro (e.g. if you need
some __declspec magic). While it is technically possible to use
the "lua" prefix (and it looks better in the debugger), this is
discouraged because LuaJIT has started to implement its own Lua 5.2+
C API functions, and with the "lua" prefix you'd violate the
one-definition rule with recent LuaJIT versions.
What's implemented
Lua
the utf8 module backported from the Lua 5.3 sources
string.pack, string.packsize, and string.unpack from the Lua
5.3 sources or from the struct module. (struct is not 100%
compatible to Lua 5.3's string packing!) (See here)
math.maxinteger and math.mininteger, math.tointeger, math.type,
and math.ult (see here)
assert accepts non-string error messages
ipairs respects __index metamethod
table.move
table library respects metamethods
For Lua 5.1 additionally:
load and loadfile accept mode and env parameters
table.pack and table.unpack
string patterns may contain embedded zeros (but see here)
string.rep accepts sep argument
string.format calls tostring on arguments for %s
math.log accepts base argument
xpcall takes additional arguments
pcall and xpcall can execute functions that yield (see
here for a possible problem with coroutine.running)
请发表评论