Coverity complains that we might read strings that are arbitrary
large, and that this can be a security issue. This is a problem in
particular, when we feed these strings to from_utf8(), which coverity
flags as dangerous for some reason.
The best solution would be IMO to model from_utf8() properly, but I do
not know how to do that. Here I try a different solution, where I
cannot read a string larger than 64k from the file.
Let's see whether this removes part of coverity warnings.
Coverity does not find it obvious that p is never negative. Normally
it is the case (because the items have been filtered), but it is
better to play safe.
The added cmake-parameter is:
-DLYX_EXTERNAL_MYTHES=<value>
where <value> is one of
AUTO (Default) Search first on system for mythes (lib and include)
ON Use installed only (errors if not installed)
OFF Compile the provided source in 3rdparty
Now configure searches in this order
1. system-installed library
2. code bundled with LyX
If --with-included-mythes or if no mythes library is installed, then
the script selects the bundled version. There should be no cases
leading to error message.
Yellow on blue causes display issues (some text elements that become black on
blue, math insets that are no longer readable). Switch to black on orange to
match the pdf output.
Use the bundled mythes by default again, since the current situaiton
create an error for anybody who does not have the system one
installed.
This is a stop gap measure and I'll return to it later (in a hurry now).
Instead of using a coverity annotation (that does not work) it is
better to really iinitialize the members of the object, just in case
somebody decides to actually use the DisplayPath() constructor.
The configure code suggests that the default for
--with-included-(iconv|zlib|hunspell) is "yes", which is wrong: by
default is indeed to use the system libraries.
Change the MyThes detection to use the system version by default.
Also add to the verison information a line which lists the bundled libraries.
Encoding cp858 is only supported by some iconv variants
Gnu iconv only supports it, if configured with "--enable-extra-encodings"
(see https://www.gnu.org/software/libiconv/)
Maybe drop support or add a configuration check?
