This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
The change to static_cast for the definition of LUAL_BUFFERSIZE replaces the fix previously used (d0100758f8) for Lua 5.3. 5.4 removes the static alternative for LUAL_BUFFERSIZE. A better solution would probably be to disable the old-style-cast warning for luaconf.h, but I can't figure out how to do that so using static_cast is the easiest solution. Do note that change will have to be applied each Lua update like the aforementioned commit.
Apparently, even on Boost 1.73 without Boost placeholders specialized as is_placeholder, they were somehow
getting used in the global namespace. Would explain all the "Boost placeholders in the global namespace is
deprecated" warnings I was getting after 23d1db043f.
When testing with BOOST_BIND_NO_PLACEHOLDERS, even though I had `using namespace std::placeholders` in utils/functional.hpp,
compilation still failed in places. This confirms even more that Boost global placeholders were being used. Honestly,
it was simplest just to specify std::placeholders for everything. This also means we can remove the hack in utils/functional.hpp
designed to allow Boost placeholders to work with `std::bind`.
This was needed to get the build working with vcpkg's version of SDL, where all the SDL files are
in their own SDL folder. However, our cmake config also has a note saying it was a deliberate choice
to move our SDL files *out* of their SDL2 folder due to certain distros (FreeBSD is mentioned) not
putting the files in said folder in the first place.
This could otherwise be used to escape the lua sandbox, as described in
multiple sources. For example one can use it to reenable the os.execute
function to do shell commands
The affected functions were
load,loadstring,wesnoth.dofile,wesnoth.require and various places in the
wesnoth source where lua chunks were loaded for example by the ai code.
This commit also changes the lua source to change luas load (which is
the same as loadstring), alternatively we could add a wrapper around the
original load function that always passes "t" as third parameter, i went
this way mostly because it was easier to implement, but also because i
was not 100% sure that is is impossible to query the upvalues of a
function via lua (wesnoth disables debug.getupvalue but still).
There is also an occurance in the application_lua_kernel that was not fixed
because i assumed that umc cannot contian application lua scipts.
As further security measure we might want to disable printing the function
adress in luas tostring for c functions, this cannot be exploited by itself
but it can be used to defeat ASLR in some cases.
(cherry-picked from commit 2554c166dd)
* Dropped unused CVideo class member references.
* Replaced the lone usecase of the CVideo member in loadgame with the singleton and removed said member.
* Removed CVideo references from a bunch of addon management functions.
* Cleaned up a *lot* of now-unnecessary forward CVideo declarations.
Covers more cases of:
* push_back(std::pair
* push_back(std::make_pair
* push_back(std::make_tuple
* push_back(T) where T is an empty object of type T
Small thing I noticed: this does mean the numbers in font::subset_descriptor are no longer 'cast' to size_t before being
added to the vector, but that shouldn't matter (hopefully).
Instead of passing the video object to the Lua kernel, the game now simply
fetches the video singleton when displaying dialogs. This means there is
no longer any need to store a reference to the video object.
luaconf.h provides a place for us to make changes, avoiding the need to change the original definitions. Move everything down there. This encompases the following changes:
1) Disable compatibility with old versions of Lua in the C++. Compatability is maintained only for the Lua runtime. Only one correction was needed: in application_lua_kernel.cpp
2) Change how the backpointer is defined, for forward compatability with Lua 5.3. This effected only one line: in lua_kernel_base.cpp. Using the Lua 5.3 macro caused a GCC warning, suppressed it for that line.
3) Certain Windows-only features are no longer available in the Lua runtime. These features are all in the Lua io module, which we don't allow access to, so this is a non-change for the runtime.
4) Lua will behave as if it is a standard C environment. This, again, mainly effects the Windows environment and features we don't allow access to in the runtime.
Do not change the released Lua source code. Lua is written as standard C, but we compile it as C++ so we can use exceptions. Change the call sites to avoid the warnings about using a C cast instead of static_cast<int>().
NB: The changes to Wesnoth C++ code will be required to upgrade to Lua 5.3, anyway.
This reverts:
commit cee3ab2084
Author: Mark de Wever <koraq@xs4all.nl>
Date: Sun Feb 5 19:55:32 2012 +0000
Fix compiler warnings.
This is the first step towards creating artificial load and testing if the
GUI2 lobby still performs well under load.
I also implemented ability to leave the game in the GUI2 MP staging dialog.
Previously the server continued to believe that the player remains in the
game when he/she closed the MP staging dialog.
@gfgtdf pointed out that preferences contain MP passwords. We can't allow
untrusted code to access them. Since we only need preference access from
plugins for now, the simplest way to avoid security issues is to block Lua
code outside of plugins from accessing preferences at all.
This constitutes drop-in replacements for:
* boost::shared_ptr
* boost::scoped_ptr
* boost::weak_ptr
* boost::enable_shared_from_this
* boost::static_pointer_cast
* boost::dynamic_pointer_cast
This excludes boost::intrusive_ptr, except for stray includes. Refactoring that is more complicated.
This commit converts the following function calls:
* boost::bind -> std::bind
* boost::function and boost::functionN -> std::function
* boost::ref and boost::cref -> std::ref and std::cref
* boost::bad_function_call -> std::bad_function_call
In the process, it was discovered that std::bind has trouble with overloaded
functions. There were two such cases in the code:
* gui2::twindow had an ancient unused overload to draw(). The overload was removed.
* gui2::trepeating_button was binding tdispatcher::fire. This case was converted
to a lambda.
headers from lua/.. contain macros that can break other headers in
wesnoth, boost or other libraries.
In this case it was a macro
#define cast(t, exp) ((t)(exp))
defined in lua/llimits.h that broke a boost header.
This key was created in the first attempt at application scripting
but it was reappropriated to be used as the key for the
"thread table" when the present solution based on coroutines was
found. The key has been renamed and moved to its site of usage now.
The problem was that intf_require would assume use the wrong
lua_State* since it finds it using the kernel's this pointer. This
commit gives a version of "protected_call" which allows to use the
callback's lua_State*.
This collection of classes provides a framework whereby the engine
may provide scripting capabilities in any "context". A C++
function may declare a plugin context by providing a list of names
function objects, then may call "play_slice()" on this context to
transfer control to lua. A lua script may generate some arguments
and request to call some of these, then yield to the engine. C++
will run them until one of them signals an error, or that the
context is now invalid (using a boolean return value).
The intended semantics is that lua may only make requests
corresponding to the current context. As soon as a new context
is used (play_slice() is called again) the old context is invalid
from lua's point of view -- calling those functions is a lua
error but not undefined behavior. This should be the case even if
the old context has not been destroyed yet in C++, for instance
if a lua request resulted in a new context being created. There is
a system of locks in place to ensure that when old contexts are
invalidated, stale requests are discarded.
We also add the coroutine library to our lua base. This because
threads are run as coroutines, and writing them requires the use
of coroutine yield from the standard library.
The lua show dialog used to get the video object from resources,
which is not ideal. In this version, lua kernel base internalizes
a pointer to the video object, and show_dialog is bound to a
method of the lua kernel base.
From now on, lua kernels which want to show dialogs need to be
constructed with a pointer to a CVideo, if it is null the lua will
fail with a runtime error.
The application lua kernel is constructed with the video for
game_launcher, and the game lua kernel is modified so that it is
owned by the play controller and not the game events manager, and
held in a boost scoped pointer rather than manually deleted. This
is because the game events manager doesn't have a video object,
also it conceptually seems independent of the lua kernel anyways.
The map generator lua kernels are constructed with NULL, but if a
user configuration dialog is provided (new feature) then when they
try to run it they will update with the mp_create's video pointer.
- Add an internal command logger to the lua kernel base, and expose
this.
- Redirect the internal lua `print` to the command logger.
- Add an external logger registration system to lua kernel, in
addition to the internal one.
- Add a lua console dialog which binds to a lua kernel base and
permits to review the contents of the logger and issue new commands,
and report errors.
- Add a hotkey binding to launch the lua console "`"
- Adds tab completion support to the lua console
In initial commit of the new lua kernels, I introduced a problem
by trying to use luaW_pcall and lua_pcall interchangeably via
polymorphism. This doesn't work because their return types don't
match, and it's alot of work to change luaW_pcall syntax. Besides
this there's no reason we can't use the custom error handler
everywhere.
This commits adds protected_call and load_string functions to lua
kernel base. These are an intended replacement for luaW_pcall,
and replace the "run" function. They do better error reporting
and allow to specify an error handler.
The error reporting is very flexible -- by default we select a
an error reporting function associated polymorphically to the lua
kernel, so the in-game lua kernel can send chat messages, and
others can do something else. However an arbitrary handler may
be specified, and exceptions instead of logging may also be
requested.
The application lua kernel is meant to interpret scripts to drive
the client. Its main features are, it stores a script in its
registry and provides a C++ function to call it with a config
as its argument. Its initialization also creates a "game_launcher"
object, which stands as a limited lua proxy for the C++
game_launcher object.
The game_launcher object is a table, holding a pointer to the
actual game_launcher it represents, and with metamethods to return
version info and the command line arguments. It also holds
callbacks to set the script for the current application lua kernel,
and to call the "play_multiplayer" function of game_launcher.
Currently it is readonly and you cannot write to its fields,
although that may change to allow the target server to be reset,
etc.
Some minor changes that are included in this commit:
- the actual C++ game launcher object provides an accessor to the
command line options.
- the scripting/lua_types.hpp file now has include guards
