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

[Paul Eggert]

On 4/30/19 2:38 PM, Adam Richter wrote:
> 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.

Since update-game-score is about to exit when the 'free' calls you're
proposing would be executed, I'm not sure the changes are that helpful:
they complicate the source code and make the executable a tiny bit
bigger and slower and don't fix any real leaks. Perhaps if we do full
LeakSanitizer checking we can put in the change then, if only to pacify
the LeakSanitizer. (It's not clear to me that LeakSanitizer is a win
either, as it also reports quite a few false alarms.)


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

There is no lib/stdint.h in the Emacs distribution. On some platforms
lib/stdint.h is built from lib/stdint.in.h. If that build process didn't
work for you, it sounds like you need need to look into what went wrong
in that build process.


>
> 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.

I don't see any bug there; could you explain? If 'width' is negative
then the macro's _w is zero, which means _n < _w cannot be true (both _n
and _w are unsigned), and so the memset calls cannot be invoked.

> nt/preprep.c

Eli can look into that one if he has the time.


> src/regex.c <--I think the tiny memory leak for compile_stack.stack is
> real.

Is this when MATCH_MAY_ALLOCATE is not defined? If so, let's not worry
about it. It's always defined, and the !MATCH_MAY_ALLOCATE code has been
removed in Emacs 27.