I mainly want to use this for random map generators, it would be
silly to rewrite this stuff in lua after we already have it in C++
(and unit tested there).
This is intended to silently fail on Unix-like platforms where no procfs
is available, and indeed that's how it works in the non-BFS
implementation of get_exe_dir(). The caller (currently a single function
in game.cpp/wesnoth.cpp) must be able to deal with this situation
in a graceful fashion.
Also preemptively block subsequent dereferences.
Hopefully somebody will eventually hit an assertion failure here and
report back to help me understand how such a situation could possibly
arise, so I can decide whether to remove the assert and leave the new
loop conditional intact or change it to match the intended behavior
(e.g. it's possible `!active || active->empty()` would be preferable in
some scenario).
Spotted by Coverity.
update_all_button's value is obtained from operator new, which will
throw if the allocation fails, so it can never be NULL in subsequent
statements.
Found by coverity.
Fixes bug #22962, reported on the forums as affecting the Swamplings
add-on from 1.10: <http://r.wesnoth.org/r41129>
This is most likely a regression from 1.8.x, as it doesn't affect 1.8.6
and the reporter on the forums claims it affected 1.10.x.
Direct substitutions do not require the instantiation of a new
preprocessor_streambuf, instead inheriting the current context's
streambuf, along with its textdomain. preprocessor_data() is then
constructed with an overruled textdomain which leads to a no-op as it is
identical to the streambuf's current textdomain.
Nested substitutions _do_ require a new streambuf created by means of
its copy constructor, which leaves the new streambuf's textdomain set to
the default of PACKAGE (defined as "wesnoth"). Then a new
preprocessor_data context is instantiated and instructed to overrule the
initial textdomain with the macro's textdomain. However,
preprocessor_data's base class constructor (`preprocessor`) has already
copied the streambuf's initial textdomain id to its previous textdomain
record, causing it to restore that textdomain on destruction instead of
the correct one.
Thus, when performing slowpath substitutions we need to make sure the
preprocessor_data and preprocessor constructors see the parent context's
streambuf textdomain instead of the wesnoth default. Later, the nested
preprocessor_data will restore the correct textdomain and emit a
trailing <FE>line directive for the parent if necessary.
The alternative of having the preprocessor_streambuf copy constructor
copy the original streambuf's textdomain would also fix this bug, but it
would break the intended behavior for slowpath file inclusions, which
always default to wesnoth. Although most WML containing translatable
strings have a #textdomain directive at the start nowadays (and this is
in fact enforced by wmllint), it's probably a bad idea to change the
current behavior in this case for UMC, at least for the 1.12.x stable
series.
I do not expect regressions from this commit and it certainly won't
cause compatibility issues or behavior changes outside i18n -- at least
for add-ons that are doing things right and not relying on translatable
strings having the wrong value.
DM, DW, DiD, EI, HttT, LoW, Liberty, SoF, THoT, TRoW, TSG, data/core,
and data/multiplayer all present preprocessor output differences before
and after this fix, but they amount to no changes to the parser's
output; unlike SotBE and UtBS, which benefit from the fix:
* data/campaigns/Son_Of_The_Black_Eye/scenarios/07_The_Desert_of_Death.cfg:439
had the {TURNS_RUN_OUT} core macro substitution bound to the
campaign's own textdomain instead of wesnoth for some reason.
* data/campaigns/Under_the_Burning_Suns/scenarios/05_A_Subterranean_Struggle.cfg:1749
onwards (the ENEMY_ATTACK and ALLY_REINFORCEMENTS macros) bound
several strings to the wesnoth textdomain instead of the campaign's
textdomain.
I also tested this commit with my own add-on, After_the_Storm, which
presented similar results as DM et al above. Finally, Swamplings is
properly fixed by this change.
this fixes a bug which caused that _final.cfg wasn't included last
becasue we compared a string with "/_final.cfg". By using
generic_string() we make sure that the seperators are '/'.
http://gna.org/bugs/?22967
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.
