Ignoring the other clang-tidy report, as it looks strlcpy is not that good (and needs libbsd), and we get these strings from luaL_checkstring which makes correct 0-terminated strings.
Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119

strncpy would work, but cppcheck will also complain about it.

The current usage is harmless anyway.

(And, yeah, we already enforce -static-libstdc++ everywhere else, so no need to wait for that ;)).

Last commit fix the last serious memory leak reported by valgrind. See #1010 (comment).

The remaining one is in crengine:

==20837== 64 bytes in 1 blocks are definitely lost in loss record 2,258 of 4,031
==20837==    at 0x4835DEF: operator new(unsigned long) (in valgrind/vgpreload_memcheck-amd64-linux.so)
==20837==    by 0x13733AB1: tinyNodeCollection::allocTinyElement(ldomNode*, unsigned short, unsigned short) (lvtinydom.cpp:12186)
==20837==    by 0x13758809: ldomDocument::ldomDocument() (lvtinydom.cpp:3374)
==20837==    by 0x1380648E: LVDocView::createEmptyDocument() (lvdocview.cpp:4366)
==20837==    by 0x1380DE7A: LVDocView::LoadDocument(LVFastRef<LVStream>, bool) (lvdocview.cpp:4003)
==20837==    by 0x13811905: LVDocView::LoadDocument(wchar_t const*, bool) (lvdocview.cpp:3784)
==20837==    by 0x13811E3B: LVDocView::LoadDocument(char const*, bool) (lvdocview.cpp:4726)
==20837==    by 0x1361B144: loadDocument(lua_State*) (cre.cpp:629)
==20837==    by 0x129D56: lj_BC_FUNCC (buildvm_x86.dasc:809)
==20837==    by 0x12A905: lj_ff_coroutine_resume (buildvm_x86.dasc:1640)
==20837==    by 0x11A09F: lua_pcall (lj_api.c:1129)
==20837==    by 0x110943: docall (luajit.c:121)

But for 64 bytes... I'll just add a comment:

@@ -3372,6 +3372,14 @@ ldomDocument::ldomDocument()
 , lists(100)
 {
     allocTinyElement(NULL, 0, 0);
+    // Note: valgrind reports (sometimes, when some document is opened or closed,
+    // with metadataOnly or not) a memory leak (64 bytes in 1 blocks are definitely
+    // lost), about this, created in allocTinyElement():
+    //    tinyElement * elem = new tinyElement(...)
+    // possibly because it's not anchored anywhere.
+    // Attempt at anchoring into a _nullNode, and calling ->detroy()
+    // in ~ldomDocument(), did not prevent this report, and caused other ones...

Serious memory leak? But, um, the icon is displayed as long as the program exists and then forgotten about. It might technically "leak" in the sense that it's not freed properly on exit, but it just lives & dies with the program. :-P

(Unless I'm missing something, it'd only be a leak when changing the icon dynamically.)

Nope, it was the png data pointer that was not free'd.
We read the png data, make a blitbuffer with it, pass it to some SDL texture stuff, which does its thing, and then we free() the blitbuffer as we (and SDL) don't need it anymore. But we forgot to free the png data, that was not done neither by us explicitely, and neither by the blitbuffer:free(). Now, we have the blitbuffer:free() do it (
Serious in the sense that it was 1.4 MB taken in the emulator process for nothing - only once, but that was still a waste :)

Sure, sure. It's just that when you say leak I think more "1.4 MB here, 1.4 MB there", even if that only happens over the course of hours or days. But it's 1.4 MB period. (Would it fit on a floppy?) :-)