[Low priority] Some minor complaints from cppcheck about emacs 26.2

[Adam Richter]

Hi, everyone.

I just tried running the version of cppcheck from the github
repository (which fixes at least one false positive report that I have
been seeing from cppcheck 1.86) on emacs 26.2 sources, and cppcheck
appears to have a found a few bugs that probably don't cause external
misbehavior, but I'm not sure are completely safe.  So, I am sending
this message with the cppcheck output attached, in the hopes that by
saving emacs developers the time of building the latest cppcheck and
doing a superficial check of the warnings, one or more people on the
list might find it worth taking a glance that the messages that I
could not rule out as completely spurious, and also in the hopes of
saving time for anyone else who runs cppcheck on emacs and sees the
same warnings.

Here is a list of files listed in the attached cppcheck and my notes about them.

lib-src/ebrowse.c  <-- Not a bug.  strdup is supposed to "leak" a malloc.

lib-src/update-game-score.c <-- I submitted a patch attached to a
message to this mailing list a few minutes ago, which I think fixes
the legitimate complaints.  The last complaint ("realloc mistake")
does not appear to be a bug.

lib/stdint.h  <-- This is a real typographical bug and I don't know
what the author intended.

lib/nstrftime.c <-- Possibly a real bug, but only if multibyte is
disabled.  A local variable "width", set to -1, is used by a macro
that I think may expect a positive value, but I am not sure of this
fix.

nt/preprep.c <-- These are complaints about
copy_executable_and_move_sections() where the variable
import_delta_rva might not be set if import_section == NULL and
rva_to_section() also returns NULL.  I am not sure if this really can
happen and if the resultant undefined value is consequential in that
case.

src/regex.c <--I think the tiny memory leak for compile_stack.stack is
real.  Everything else is probably not a legitimate complaint,
although I'm not 100% sure about that.  I think the "Uninitialized
variable" complaints about len and buf_charlen are all wrong, possibly
due to cppcheck trying all combinations of #ifdef's and perhaps
finding one that does not define the macros that set these variables.

src/regex.h <-- This complaint seems completely spurious (use of
#ifdef in the middle of a function declaration).

lib-src/etags.c <-- I believe that this complaint about a possible
null pointer dereference is spurious because filename_is_absolute()
would need to return true in one place and false in another with the
same data in order for that to happen.

Anyhow, if anyone has any questions, please feel free to ask me or
discuss on this list, as you think appropriate.  I hope this
information is helpful.

Adam

emacs-26.2.cppcheck.log
Description: Binary data