This has been discussed on the mailing list. While there wasn't much
input, the consensus was that it should be allowed for consistency with
std::string.
While most engines don't do this, it is possible that some engines will
break because of it. (A few have already been fixed.) But it will also
repear the currently broken ADL engine. For now, the warning() message
will remain so that it can be investigated on a case-by-case basis.
This is not the best solution as it removes the warning when this
code is used by devtools such as create_titanic, but getting this to
link would need inclusion of textconsole.o via shim and then still
breaks on g_system, so fastest solution to restore build.
While it's not needed to build ScummVM, apparently some of the other
tools that use String do not include textconsole.h and complain that
warning() is undefined.
Some engines do this, and it's not really known what should happen. We
need to decide on a behavior, and stick to that. This warning is to help
find where it happens.
From my own tests, it can happen in at least ADL, Avalanche, Chewy,
Director, Blazing Dragons, MacVenture, MADS, Prince, Stark, Startrek,
and Trecision. Only ADL is known to be broken by the current behavior.
The result of my test can be found at
http://www.update.uu.se/~d91tan/tmp/string.txt
The string memory pool mutex lock/unlock were lost during the
merge of String and U32String. This caused the cloud feature
to randomly crash for example when synchronizing savegames or
downloading game data.
Different platforms have different levels of support of encodings and
often have slight variations. We already have tables for most encoding
with only CJK missing. Full transcoding inclusion allows us to get reliable
encoding results independently of platform. The biggest con is the need for
external tables encoding.dat.
It removes a duplicate table for korean in graphics/korfont.cpp
Remove a useless creation of a BaseString object with a C string in
comparison operators of this class, because there is a function
equals() that accepts a C string in parameter.
The call to decRefCount has been moved to the destructor
of the base class BaseString.
Note that BaseString only exists for the purpose of being able
to reuse code for our String and U32String implementations. As
such it is not meant to be used polymorphically and its
destructor does not need to be virtual (with the overhead that
this generates). And to ensure that it is not used in a
polymorphic way, the destructor is declared protected.
Appending \0 to string and expecting it to be just dropped is
still an invalid behaviour but it already happened in 2 engines, so
restore old behaviour, at least for now
